-
Notifications
You must be signed in to change notification settings - Fork 26
improve Dart constructor design #163
Comments
#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. |
CC @rakudrama who hit this looking at our (abysmal :) ) runtime performance. |
Suspect the right fix here nowadays is just generate something uglier in JS if needed. Maybe we split out ctors and initializer methods. |
FWIW, we could certainly change to spread/rest args and have the base Object |
|
This issue was moved to dart-lang/sdk#28322 |
(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 JSconstructor
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).
The text was updated successfully, but these errors were encountered: