Could you outline the differences between Scala and Ceylon constructors, for readers not familiar with both?
Similarities:
- Scala has the notion of a “primary” constructor vs “auxiliary” constructor, which at first looks sorta superficially similar to the notion of a “default” vs “named" constructor in Ceylon.
- Both Ceylon and Scala (and Java, and C++, and C#, etc) have a notion of delegation between constructors.
Differences:
- In Scala, constructors are overloaded, that is, they are distinguished by the types of their parameters. In Ceylon, they have distinct names, and are distinguished by name.
- In Scala, every auxiliary constructor of a class must ultimately delegate to the primary constructor. In Ceylon, there is is no such restriction. Any constructor may delegate directly to the superclass. Given this, I can't see how it's possible for two constructors of a Scala class to delegate to different constructors of the superclass. That's possible in Ceylon.
- In Scala I could not find any way to assign to an immutable member (val) from an auxiliary constructor. At first I thought that this could not possibly be a real limitation, but, checking stack overflow, it seems that it is. Auxiliary constructors can only assign to vars? Really?!
- In Ceylon, initialization flows from the top of the class body to the bottom, allowing. In Scala it jumps around: all statements of the primary constructor are executed, even statements that occur after the auxiliary constructors, and then the auxiliary constructors.
- Ceylon has the notion of a partial constructor which partially initializes the class, but may only be called by other constructors. Scala doesn’t seem to have this concept. Indeed, the primary constructor must initialize all fields. And, if I understand correctly, the only thing that auxiliary constructors are allowed to do is mess with mutable members and perform side-effects. (Of course, it’s a bad practice to make constructors side-effecty.)
- Ceylon has the notion of a value constructor. I have not yet found anything like that in Scala.
- Taking a reference to a constructor and treating it as a function seems to be quite uncomfortable in Scala. In Ceylon it's very natural. Also Scala sometimes seems to demand the use of the "new" operator in instantiation expressions, though I'm not clear why that's a requirement.
My bottom line conclusion is that constructors in Scala are much less powerful than I had imagined they would be, and, it seems, much less powerful than constructors in Ceylon. Of course, some of what I’ve written here could be incorrect, since I’m not a Scala programmer. If so, I’m hoping someone will correct me.
Anyway, I definitely haven’t found anything in Scala constructors that we should have reproduced in Ceylon. Can someone else find something?
Less is more. Nobody needs or wants the mess of Java-style initialization Ceylon tries to replicate.
Ceylon has the notion of a value constructor.
I have not yet found anything like that in Scala.
Also Scala sometimes seems to demand the use of the "new" operator in
instantiation expressions, though I'm not clear why that's a requirement.
Constructors in Scala are intended to directly initialize fields. They shouldn't be called directly, and are often private. Factory methods provide everything else, and are declared in objects, instead of being static like in Ceylon. That's by-design.
Because you care about the "outcome", not the "process": Scala did away with 90% of the mess associated with constructors, and used existing general-purpose features of the language to provide the rest (instead of having to introduce named constructors, default constructors, value constructors, partial constructors, and constructs which are "static" but named differently ...).
I don't think anything can change your idea that the thing you invented is the best thing ever (and everything else doesn't apply, because of the special constraints of Ceylon), therefore have a nice day! :-)
(Secondary) constructors are discouraged.
Initialization in Ceylon is nothing like initialization in Java:
- For the simple (common) case where there is exactly one initialization path, Ceylon is far less verbose.
- In Ceylon, the compiler guarantees that ever field not marked variable is assigned exactly once.
> Yet another static thing in class declarations?
Not really, just a constructor with no parameters.
Constructors are not "static". Constructors access the members of the class.
> Constructors in Scala are intended to directly initialize fields.
But it seems to me that they can't. Isn't it correct that only the primary constructor can initialize vals?
> Constructors in Scala are intended to directly initialize fields. They shouldn't be called directly, and are often private.
AFAICT it is not a limitation of the Scala language that constructors shouldn't be called directly. If it's indeed a practice that constructors aren't called directly, then it's interesting to enquire why that might be. And indeed an answer presents itself: because they don't have names.
> Factory methods provide everything else, and are declared in objects, instead of being static like in Ceylon.
Wait: a factory method declared on a "companion object" is not like static?! Really?
And it seems to me that people probably hide constructors behind factory methods precisely because constructors in Scala don't have names. I mean AFAICT, the syntax for calling a factory method of a companion object in scala is exactly the same as the syntax for calling a constructor in Ceylon! You just have to go through a whole lot more ceremony in Scala.
> Scala did away with 90% of the mess associated with constructors
And, AFAICT, also lost like 75% of their capabilities. Unless my evaluation above is wrong, and I'm missing something. But so far no-one has spoken up to correct me.
> therefore have a nice day! :-)
You too!
Constructors are not "static". Constructors access the members of the class.
Color foo = ...; new foo; // doesn't make any sense.
If it's indeed a practice that constructors aren't called directly, then it's
interesting to enquire why that might be. And indeed an answer presents itself:
because they don't have names.
Wait: a factory method declared on a "companion object" is not like static?! Really?
- Static members inside objects
- Static methods inside classes (with new x() {...})
- Static fields inside classes (with new x {... }
I mean AFAICT, the syntax for calling a factory method of a companion object in
scala is exactly the same as the syntax for calling a constructor in Ceylon!
And, AFAICT, also lost like 75% of their capabilities.
Unless my evaluation above is wrong, and I'm missing
something. But so far no-one has spoken up to correct me.
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 to have one entry-point to create an instance, not 5.
I don't understand how having a factory method on a Scala companion object that calls an overloaded constructor of a Scala class is not a separate "entry-point". I count each of those factory-method-constructor bundles as one entry-point. And even if these factory methods all call the same constructor, they still seem like separate "entry-point"s.
And apart from your assertion that a single "entry-point" is good design, I don't quite see any particular reason to believe it. You've offered no arguments for this assertion.
> In Scala you have one place for "static" things. In Ceylon, static is all over the place:
Scala has members of objects and constructors of classes. Ceylon has members of objects and constructors of classes. Where is the difference? OK, so in Ceylon I can have a constructor which does not declare any parameters. How does that amount to being "all over the place" compared to Scala.
> Yes. Ceylon wasted the "good" syntax on the wrong construct. Most of the patterns leveraged in factory methods are just not available in Ceylon, because the best syntax was directly married to the class.
Well you see this is where Scala starts to look really bad. The problem is that Scala has no plain functions. Scala forces you to write methods of objects. In Ceylon we have toplevel functions, so we just don't need to go around sticking functions on the side of classes like you do in Scala.
> Everything Ceylon has built into "constructors" are just standard methods with no magic required in Scala.
This is simply false. You can't emulate constructors with plain methods in a language which enforces immutability / single-assignment. If you could, we would have done it that way.
> Yes, constructors are not extremely powerful – because they don't need to be in Scala.
Well, I never claimed that Scala needed constructors. Indeed I never mentioned Scala until people started trying to say—incorrectly to the point of absurdity, as it turns out—that Ceylon had copied its system of constructors from Scala.
Indeed you were one of those people. You entered this discussion with the following attack on me:
> A language designer which doesn't want to give credit where credit is due
I'm still waiting for you to retract that, now that I've conclusively demonstrated that Ceylon's constructors are totally different to—and more powerful than—Scala's.
A language designer which doesn't want to give credit
where credit is due
I'm still waiting for you to retract that, now that I've
conclusively demonstrated that Ceylon's constructors are
totally different to—and more powerful than—Scala's.
A) You conveniently left out the other part of the sentence.
B) I already commented on that topic very early on, and clarified:
Ok ... I'm really starting to believe you when you said you
didn't look into that other language, because there is
practically no benefit in doing it the way Ceylon does.
I never said that. Please don't put words into my mouth.
Ceylon's constructors are totally different to—and more
powerful than—Scala's
Whatever, your attack on me was totally uncivil and unjustified, as you now realize, which is why you're backpedalling it so furiously. You've never interacted with me before, and so coming in here with a blazing personal attack was completely unreasonable behavior. I think you see that, so let's just drop it now.
> Ceylon's approach isn't very good in terms of language complexity.
Here's another assertion for which you simply have not provided evidence. How are Ceylon's constructors more "complex" than Scala's constructors? The actual syntactic weight of both constructs is almost identical. And in terms of complexity, the factory-method-on-a-companion-class pattern is significantly more complex in terms of ceremony than doing the equivalent thing in Ceylon.
Look man, stepping back a second, I can see that you're clearly a fan of Scala and that Scala is something you love and enjoy. That's great! But Scala isn't perfect and other languages can have good ideas too. I highly recommend you spend some time learning Ceylon, since it has a bunch of awesome things in it that I know you'll love: the things we can do with union and intersection types, disjointness, abstraction over tuple and function types, etc, are just beautifully elegant and powerful. Don't let the fact that you love Scala blind you to other ideas.
the things we can do with union and intersection types,
disjointness, abstraction over tuple and function types,
etc, are just beautifully elegant and powerful. Don't let
the fact that you love Scala blind you to other ideas.
Given there are some things I can't just suffer anymore, like unreadable Generics (<>), required ; and "Type ident" syntax, maybe Ceylon just isn't for me. :-)
Well it's really lovely and encouraging to see Ceylon exercising such a strong influence on Scala. Makes me very proud.