improve Dart constructor design #163
Description
(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).