Skip to content
This repository was archived by the owner on Feb 22, 2018. It is now read-only.

improve Dart constructor design #163

Closed
jmesserly opened this issue May 4, 2015 · 6 comments
Closed

improve Dart constructor design #163

jmesserly opened this issue May 4, 2015 · 6 comments

Comments

@jmesserly
Copy link
Contributor

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

@jmesserly
Copy link
Contributor Author

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

@jmesserly jmesserly changed the title improve Dart constructor design to work with strong mode improve Dart constructor design Jun 23, 2015
@jmesserly
Copy link
Contributor Author

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

@jmesserly
Copy link
Contributor Author

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

@jmesserly
Copy link
Contributor Author

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.

@jmesserly jmesserly self-assigned this Apr 29, 2016
@jmesserly
Copy link
Contributor Author

jmesserly commented Apr 29, 2016

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

@vsmenon
Copy link
Contributor

vsmenon commented Jan 10, 2017

This issue was moved to dart-lang/sdk#28322

@vsmenon vsmenon closed this as completed Jan 10, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

2 participants