Comments on Hummus and Magnets: Constructors #2

Hi Burak, thanks for your comments.

I do ha...

2008-04-06T22:47:00.000+02:00

Hi Burak, thanks for your comments.

I do have a lot of opinions on Scala for someone who hasn't really ever used it, don't I. In this case, I didn't actually know about the new Bar { ... } mechanism. It does indeed look very similar and seems to avoid partial initialization problems (modulo the behavior of Bar's constructors). However, as far as I understand the mechanism it only works for leaf classes, you have to use standard constructors to build deeper inheritance hierarchies. Is there a way to use this to express the example from the post where both Point2D and Point3D are free to switch their internal representation without requiring changes to each other or client code, and where partial initialization can't occur?

(I'm curious -- if you're not a fan of object orientation do you know of an alternative solution to this problem in a different paradigm?)

Extractors do give the data abstraction I think is missing with case classes; I also like the pattern matching mechanism in F#. I'm not sure either solution gets it exactly right but on the other hand I can't think of any way to improve them.

Even though new methods are no different from others and you might as well have called Point.at(x: 0, y: 0) I think the code becomes easier to read if people use the same method name more or less consistently. The special syntax is there to encourage that, and to make construction expressions stand out more. But in the language I'm working on syntax is cheap -- the new expression is not built in, it's just a convenience added by a library.

You're right about the translation of new methods and, in the simple case, the implementation of keyword arguments is relatively straightforward. It's a little more complicated than tuples since you have to be able to reorder the arguments. Calling f(a: 3, b: 4) and f(b: 4, a: 3) should have the same effect except for the evaluation order of the arguments.

Christian, I feel like adding here a couple of poi...

2008-04-06T18:52:00.000+02:00

Christian, I feel like adding here a couple of points

1. To Scala's defense, a lot of design choices and limitations stem from the we-will-always-compile-to-JVM doctrine. This also includes that you should be knowing what you should not be doing when you call a virtual method from within a constructor.

2. In addition to those limitations, Scala's virtual types are directly tied to constructors - if a class has a type member Foo, then (similar to generics), one has to make a choice for "type Foo". Syntax like new Bar { type Foo = String; val x = 3; val y = 4 } is pretty elegant, consistent and straightforward and I find your comments regarding Scala constructors do not seem to cover this side of object construction (which looks somewhat similar to your own).

3. Sometimes I think un-object-oriented is a compliment, but more to the point, I agree that case classes are in conflict with data abstraction, that is why there are extractors now to provide a more fine-grained approach to pattern matching. In newer versions of Scala, a case class is translated to a static method call behind the scenes (case class Bar becomes object Bar with an "apply" method and a class Bar). The apply method plays the same role as the static factory methods.

4. (This could answer the question of the previous comment) If new Foo is the same as Foo.new, why provide syntax for it?

BTW, an answer for the question in the previous comment, if it is the same as in Scala, a constructor call new Foo(arg1,...,argN) becomes Foo.new(arg1,...,argN). For Scala case classes, a call Foo(arg1,...,argN) becomes Foo.apply(arg1,...,argN). I guess making it work with named parameters is not hard, as fixed-length records are really the same as tuples.

If new X() is equivalent to X.new(), then what is ...

2008-01-03T16:04:00.000+01:00

If new X() is equivalent to X.new(), then what is new X() { x: 3, y: 4 } equivalent to?

I'm not much of a fan actually.

In Scala, a...

2008-01-02T21:58:00.000+01:00

I'm not much of a fan actually.

In Scala, as in Java, you have free access to the object being initialized during initialization and you can execute arbitrary code in context of that object. That has some unfortunate consequences. For instance, if a superclass constructor happens to invoke a method that has been overridden in a subclass then the method will be executed before the subclass has had a chance to initialize itself. This can cause some very subtle and unintuitive bugs, especially if there is no immediate error but you just silently propagate some inconsistent values. And of course if initialization code happens to throw an exception then you get a broken object. This model also makes it impossible to have real immutable fields and only a more complicated approximation, like finals in java, is possible.

The part worst part of scala constructors, though, is the way they are tied to pattern matching in case classes. There you get direct access to the object's fields which ties code not only to a particular implementation of an object but to the way in which the object was constructed. That seems very un-object-oriented.

How do you feel about Scala's approach to construc...

2007-12-31T19:54:00.000+01:00

How do you feel about Scala's approach to constructors?