improve Dart constructor design

[vsmenon]

From @jmesserly on May 4, 2015 16:48

(Original context #51 and #162)

All Dart constructors are currently instance methods, as it's the only way to generate simple code with super. Once classes are finished in V8 (https://code.google.com/p/v8/issues/detail?id=3330) we can revisit constructors to see if there's a better pattern. I would really like to use real JS constructor whenever possible; currently only core.Object has a "real" constructor. The current pattern should basically work though, as long as we mixin the initializer logic any time we're extending a native type (currently just Object, but in the future, Custom Elements too).

However, I'm not sure it will interact well with strong mode in the future. Last I checked, "use strong" mode's preferred initialization order is backwards from Dart's (superclass fields first, instead of subclass fields first), so it's going to be tricky. Perhaps we can solve this with analysis to determine if initializers have side effects (hard in general, but perhaps doable for initializers, as they tend to be simple?) or a way programmers can simply tell us they don't care (because really, initializers shouldn't have side effects in a well designed program).

Copied from original issue: dart-archive/dev_compiler#163

[vsmenon]

From @jmesserly on May 5, 2015 16:36

#162 points out the current pattern is actually broken, if the named constructor has the same name as an inherited member. Unlike all other cases where member name conflicts are statically rejected, that one is allowed. Yet another nudge towards changing how named constructors work.

[vsmenon]

From @jmesserly on April 27, 2016 0:48

CC @rakudrama who hit this looking at our (abysmal :) ) runtime performance.

[vsmenon]

From @jmesserly on April 27, 2016 0:49

Suspect the right fix here nowadays is just generate something uglier in JS if needed. Maybe we split out ctors and initializer methods.

[vsmenon]

From @jmesserly on April 27, 2016 16:27

FWIW, we could certainly change to spread/rest args and have the base Object constructor() jump to our initialize method which has a known name. I'm not sure that would help much, though. The initializer method was basically a door to get out of the (silly) ES6 constructor restrictions.

[vsmenon]

From @jmesserly on April 29, 2016 22:40

Taking a shot at this hmm, nothing jumped out as a great solution, going to leave for now

[jmesserly]

This was tackled: we now use ES5 constructors for better performance. Default constructor is called .new