4 ms·

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

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 them, so I don't see why I should be expected to mention Scala, when it had no influence at all on the design of this functionality. To be clear, I find it highly unlikely that Scala constructors are very similar to what I describe in this post, except perhaps on the most superficial level. I will take a look at Scala later today to confirm that, just in case I'm wrong. I'm not sure what argument is being made in the rest of your comment. Perhaps you could elaborate on what are your concerns?

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?
- perneto 11y ago
  Could you outline the differences between Scala and Ceylon constructors, for readers not familiar with both?
  - 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?
    - perneto 11y ago
      Of course! No need to rush.
    - duaneb 11y ago
      Please look at "case classes" and their associated constructors, which is where I see the most similarity. I am sure they are implemented very differently, but I am not sure exactly what the benefits of ceylon might be over a more "cluttered" scala-style approach built on top of java class-and-interface MRO.
      - 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.
  - 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 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?
duaneb 11y ago
There is a large overlap between what you call the default constructor and scala case classes—there is a primary "value" parameter list, and other constructors must be defined in those terms. My comment was not meant to be an argument, just a note that there are similarities between this and the other major contender for "java/javascript replacement" and you don't bother to mention them. If they are different, you don't bother to say that either. So it's not a very useful without the comparison, it's just tweaking of the language's constructor patterns and calling it novel.
- justthistime_ 11y ago
  Not sure what scares me more: A language designer which doesn't want to give credit where credit is due, or a language who really didn't do his research. Too bad that Ceylon/Dart still haven't caught up with the state of the art in terms of "named/default constructors".
  - 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" design, or a link to some research that you think I didn't do? Because if not, it doesn't seem that scary, does it?
    - justthistime_ 11y ago
      The whole idea of "let's encourage people to litter their classes with convenience constructors" is bad. Constructors are the odd things which act like static methods, but have access to the fields of the instance-to-be-created. Because constructors are weird and special in a lot of other ways too, it makes sense to use them only for initialization, and try to encourage people to define exactly one constructor. Named constructors are poorly designed factory methods with the disadvantage that they are married to the class and add additional baggage to class declarations. Why does Ceylon have objects, if they aren't used for one of their prime use-cases? "Static methods go into objects, except static factory methods, let's keep dumping them into the class declaration" ... looks quite questionable to me. 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.
stephen 11y ago
Given you're a language designer, I'm really surprised you have not looked at Scala enough to know how it handles constructors. Scala is also your biggest competitor (IMO) on the JVM, which makes it even more odd that you seem to not have looked at it deeply. (I'd understand not reading the latest DOT type calculus/whatever paper, but this is basic syntax/usage.) Totally your call of course, but stealing the best ideas, in any endeavor, is usually the best way to go. Even if you decide to not steal Scala's constructors, that's fine, it's awesome if you have something better, but to have not even evaluated them... Just surprised.
- 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 syntax and semantics, including a set of principles about how the block structure of the language works, rules about definite initialization, the fact we don't have overloading, etc, etc, which are quite specific to _Ceylon_, and aren't found in other similar languages. These constraints were pretty much sufficient to fully determine the resulting design. Furthermore, there was an issue open in Ceylon's issue tracker for almost 2 years, following on from discussions and proposals in two other issues that go back even further, and these issues were read and commented on by many of our community members, including some who have some Scala experience. Now, if you could point to some cool idea in Scala that we obviously aren't aware of, and which could have improved the design of constructors in Ceylon, then I guess you would have a point. But it doesn't seem like you do have anything concrete, just a concern about _process_ rather than _outcome_. And fundamentally I'm a guy who cares about outcome. And I think the outcome is rather excellent.
  - jules 11y ago
    I think what they're saying is that it's good to give credit where credit is due.
    - gavinking 11y ago

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?

perneto 11y ago
Could you outline the differences between Scala and Ceylon constructors, for readers not familiar with both?
- 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?
  - perneto 11y ago
    Of course! No need to rush.
  - duaneb 11y ago
    Please look at "case classes" and their associated constructors, which is where I see the most similarity. I am sure they are implemented very differently, but I am not sure exactly what the benefits of ceylon might be over a more "cluttered" scala-style approach built on top of java class-and-interface MRO.
    - 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.
- 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 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?

duaneb 11y ago

There is a large overlap between what you call the default constructor and scala case classes—there is a primary "value" parameter list, and other constructors must be defined in those terms. My comment was not meant to be an argument, just a note that there are similarities between this and the other major contender for "java/javascript replacement" and you don't bother to mention them. If they are different, you don't bother to say that either. So it's not a very useful without the comparison, it's just tweaking of the language's constructor patterns and calling it novel.

justthistime_ 11y ago
Not sure what scares me more: A language designer which doesn't want to give credit where credit is due, or a language who really didn't do his research. Too bad that Ceylon/Dart still haven't caught up with the state of the art in terms of "named/default constructors".
- 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" design, or a link to some research that you think I didn't do? Because if not, it doesn't seem that scary, does it?
  - justthistime_ 11y ago
    The whole idea of "let's encourage people to litter their classes with convenience constructors" is bad. Constructors are the odd things which act like static methods, but have access to the fields of the instance-to-be-created. Because constructors are weird and special in a lot of other ways too, it makes sense to use them only for initialization, and try to encourage people to define exactly one constructor. Named constructors are poorly designed factory methods with the disadvantage that they are married to the class and add additional baggage to class declarations. Why does Ceylon have objects, if they aren't used for one of their prime use-cases? "Static methods go into objects, except static factory methods, let's keep dumping them into the class declaration" ... looks quite questionable to me. 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.

stephen 11y ago

Given you're a language designer, I'm really surprised you have not looked at Scala enough to know how it handles constructors. Scala is also your biggest competitor (IMO) on the JVM, which makes it even more odd that you seem to not have looked at it deeply. (I'd understand not reading the latest DOT type calculus/whatever paper, but this is basic syntax/usage.) Totally your call of course, but stealing the best ideas, in any endeavor, is usually the best way to go. Even if you decide to not steal Scala's constructors, that's fine, it's awesome if you have something better, but to have not even evaluated them... Just surprised.

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 syntax and semantics, including a set of principles about how the block structure of the language works, rules about definite initialization, the fact we don't have overloading, etc, etc, which are quite specific to _Ceylon_, and aren't found in other similar languages. These constraints were pretty much sufficient to fully determine the resulting design. Furthermore, there was an issue open in Ceylon's issue tracker for almost 2 years, following on from discussions and proposals in two other issues that go back even further, and these issues were read and commented on by many of our community members, including some who have some Scala experience. Now, if you could point to some cool idea in Scala that we obviously aren't aware of, and which could have improved the design of constructors in Ceylon, then I guess you would have a point. But it doesn't seem like you do have anything concrete, just a concern about _process_ rather than _outcome_. And fundamentally I'm a guy who cares about outcome. And I think the outcome is rather excellent.
- jules 11y ago
  I think what they're saying is that it's good to give credit where credit is due.
  - gavinking 11y ago