[justthistime_]

Looks like you are missing the point completely with your focus on Scala constructors:

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.

Yet another static thing in class declarations? Inventing different names for "static" doesn't solve the issue that you have introduced both "static" and "object" into the language. That's not a good idea.

  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.

It's the same reason why instanceOf/casting is x.isInstanceOf[X]/x.asInstanceOf[X] instead of adding "convenience" syntax. You can't discourage people to use something and then provide syntax sugar for it.

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! :-)

[gavinking]

> 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, 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!

[justthistime_]

  Constructors are not "static". Constructors access the members of the class.

That doesn't mean that they are not "static". Yes, they sit in a weird middle-ground, but fact is that constructors are called on the class/type, and not on the instance.

  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.

No, because it is good design to have one entry-point to create an instance, not 5. It is hard enough with reflection, sun.misc.Unsafe and serialization as-is.

  Wait: a factory method declared on a "companion object" is not like static?! Really?

In Scala you have one place for "static" things. In Ceylon, static is all over the place:

  - 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!

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.

  And, AFAICT, also lost like 75% of their capabilities.

Which has not been a issue in the last 10 years of Scala. Everything Ceylon has built into "constructors" are just standard methods with no magic required in Scala.

  Unless my evaluation above is wrong, and I'm missing 
  something. But so far no-one has spoken up to correct me.

Yes, you are focusing on the power of constructors. Yes, constructors are not extremely powerful – because they don't need to be in Scala. You are missing that Scala provides that power without turning constructors into such a mess.

[gavinking]

> 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 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.

[justthistime_]

    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. 

Eh. What?

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.

To which you – confusingly – replied with:

  I never said that. Please don't put words into my mouth.

So what do you actually want?

  Ceylon's constructors are totally different to—and more 
  powerful than—Scala's

Yep. I didn't deny that. It's a good thing though, because Ceylon's approach isn't very good in terms of language complexity.

[gavinking]

I never said I've never looked at Scala. I think you can tell from my responses to you in this thread that I'm in fact quite knowledgeable about Scala. What I said was that I had not looked closely at how Scala does constructors and that they were not an inspiration behind the design of constructors in Ceylon.

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.

[justthistime_]

  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.

I don't think it's a blind love, but all those things will ship in one of the next versions of Scala, too.

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. :-)

[lukedegruchy]

Sorry, but I don't understand your point about instanceof/casting and how this relates to constructors. Please elaborate.

[justthistime_]

Things that are discouraged don't receive the language's nicest syntax.

(Secondary) constructors are discouraged.

[lukedegruchy]

What well-designed language doesn't do this?

[justthistime_]

Ceylon and Kotlin are two languages who did this (both instanceOf/cast and instance creation).