Skip to content

improve Dart constructor design #28322

Closed
Closed
@vsmenon

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2A bug or feature request we're likely to work onweb-dev-compiler

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions