gavinking

9 ms·

31.
by gavinking 11y ago
> Yes, just for clarification, that was my point. OK cool. Then my response is simply that we took a whole lot of community feedback, as always, over a span of years , both on the issue tracker and on our Gitter (previously IRC) channel
32.
by gavinking 11y ago
> fact is that constructors are called on the class/type, and not on the instance. But this is the case in Scala too. So I really don't understand the distinction you're trying to make. > No, because it is good design t
33.
by gavinking 11y ago
Wait, you're not talking about constructors here. You're talking about the idea of giving a class a parameter list? A feature that I independently came up with about 7 years ago, before I - or most other people - had even heard of
34.
by gavinking 11y ago
No, because that pattern is still strictly more powerful. With enumerated classes I can have cases which are a class rather than just a singleton instance.
35.
by gavinking 11y ago
> Nobody needs or wants the mess of Java-style initialization Ceylon tries to replicate. Initialization in Ceylon is nothing like initialization in Java: - For the simple (common) case where there is exactly one initialization path, Ce
36.
by gavinking 11y ago
Right, so at that point, as I say, there's really not much daylight between "class" and "record". The difference being that a class protects its initialization logic (favoring modularity), whereas a record opens it
37.
by gavinking 11y ago
Name the "uncanny" similarities please. If you can't, I might think you're trolling. To be fair, it's nice to see you acknowledge that there are "obviously some differences". Some tiny little subtle differ
38.
by gavinking 11y ago
Well the issue in my mind is how to functionally decompose construction of a record. You have to come up with some way to express a "partial" record, and then "augment" it with new members. I'm trying to say this wi
39.
by gavinking 11y ago
Wait, wait, wait: just two hours ago you were demanding that I give credit to Scala for the design of constructors in Ceylon. And you accused me of quote "just tweaking of the language's constructor patterns and calling it novel&q
40.
by gavinking 11y ago
Well since zero credit is due to Scala (read my post below where I utterly demolish the claim that Ceylon constructors are similar to Scala) then doesn't that seem like an utterly rude and obnoxious demand to you?
41.
by gavinking 11y ago
Well in fact constructors aren't that much like static methods at all. Now static methods really are a weird thing, because they break the block structure of the language: they look like they have access to members of the class, but th
42.
by gavinking 11y ago
I understand, but once you start taking into account other requirements, like the ability to functionally decompose construction of this record, you will wind up with something that looks painfully similar to a class in Ceylon.
43.
by gavinking 11y ago
So if you scroll down, you'll find my tentative evaluation of Scala's support for constructors. I have not found anything of interest there. Indeed, if my understanding is correct, constructors in Scala have extremely limited ca
44.
by gavinking 11y ago
The equivalent of Scala's case classes is an enumerated class with an "of" clause. Constructors aren't really relevant here, AFAICT.
45.
by gavinking 11y ago
OK, so, here’s a tentative list of similarities / differences. Please correct me if I've made a mistake. Similarities: - Scala has the notion of a “primary” constructor vs “auxiliary” constructor, which at first looks sorta superf
46.
by gavinking 11y ago
Well I guess it's not extremely clear to me how a "record literal with open recursion" isn't essentially the same thing as a "class".
47.
by gavinking 11y ago
Yes, I think that's certainly what we've tried to achieve. It sounds like you and I have the same mental model, at least.
48.
by gavinking 11y ago
Wait, Scala's "case classes" are an implementation of what are called "sum types" in PL theory. Ceylon also has sum types, but they don't have anything much at all to do with _constructors_. If you want to know
49.
by gavinking 11y ago
OK, well it seems quite likley you're just trolling me here, but I'll respond anyway: do you have some technical feedback on how the design I've outlined here is flawed or inferior to some other "state of the art" d
50.
by gavinking 11y ago
I guess I don't understand what you're saying here. I was already aware of the concept of a constructor, from years of Java. And I already had a set of really extremely tight design constraints in terms of the existing language sy
51.
by gavinking 11y ago
Yes of course. I'm at the gym right now, so give me a chance to get home, read up on Scala so I can be sure I'm not saying anything wrong, and then I'll reply. Is that OK?
52.
by gavinking 11y ago
Yeah, OK, I just had a quick look, and Scala constructors seem to have almost nothing in common with the design I outline in this blog, other than being, well, constructors. Perhaps you didn't read the linked article?
53.
by gavinking 11y ago
So it seems to me that if you need multiple constructors then it's worth being able to give them names, in order to identify their purpose. I have never looked at how Scala handles constructors, beyond being dimly aware that Scala has
54.
by gavinking 11y ago
Because the post is dealing with the new functionality we've added in Ceylon 1.2, which provides support for Java-style (i.e. multiple) constructors, not the functionality that has always existed in Ceylon, where parameters of the clas
55.
by gavinking 11y ago
Right, exactly. So there's two very distinct cases here: - the simple and overwhelmingly common case where there is only one way to instantiate a class, and therefore there is no reason to decouple the body of the class from the parame
56.
by gavinking 11y ago
Totally this!
57.
by gavinking 11y ago
No, the alternative is this: class Point(shared Float x, shared Float y) { string => "(``x``, ``y``)"; } I think I made that really clear in the post. In the very example I started with, but perhaps I need
58.
by gavinking 11y ago
Sure. A class is certainly a kind of function: one which returns a closure over its own shared declarations. That's the way we conceptualize the notion of a class in Ceylon, and it's why the syntax for a class looks so much like t
59.
Constructors in Ceylon(ceylon-lang.org)
42 points by gavinking 11y ago|76 comments
60.
Ceylon language at the virtual JUG(youtube.com)
6 points by gavinking 12y ago|0 comments

More ›