Class data member declarations proposal idea

# Aaron Gray (10 days ago)

I am looking for help working on a TC39 proposal for declaring class data members, their default values, and possibly annotated typing. The fact that this is missing means there is little continuity between classes and existing prototypical object declarations. I have been moving Backbone.js and Underscore.js to modern class'ized JavaScript and have found that this will be needed for moving existing JavaScript libraries forward.

abstracted syntax example :-

class X extends Y {
    constructor() { ... }
    defaults = {
        a: 1,
        b: 2
    }
    x : Integer = 3
    aMethod() { ... }
}

syntax modifications :-

ClassElement [Yield, Await]:
    MethodDefinition [?Yield, ?Await]
    "static" MethodDefinition [?Yield, ?Await]
    FieldDefinition
    "static" FieldDefinition
    ;

FieldDefinition:
    Identifier "=" PrimaryExpression

This is probably slightly oversimplified at this stage with the syntactic rules, but this gives a preliminary idea of what is being proposed. This is similar to the following proposal tc39/proposal-class-fields but I have shown the idea of declaring subobject default value declarations.

Type annotations would also be a good idea and allow at the least initial type checking for the default values, but this would not fit with subobject declarations and is a very complex area to take forward for any more level of type checking, although Facebook's Flow and MicroSoft's TypeScript, and a Babel plugin flow-runtime demonstrate that this is possible. codemix/flow

# Waldemar Horwat (10 days ago)

See this proposal, currently at stage 3: tc39/proposal-class-fields

 Waldemar
# Isiah Meadows (10 days ago)

Check out the various class-related proposals at tc39/proposals. This is practically identical to the existing class field proposal, just mod the type annotation thing.

# Aaron Gray (9 days ago)

On Tue, 7 Aug 2018 at 22:34, Waldemar Horwat <waldemar at google.com> wrote:

See this proposal, currently at stage 3: tc39/proposal-class-fields

Yes I did reference the proposal my mail.

# Ranando King (9 days ago)

Did you see any similarity with my proposal-object-members rdking/proposal-object-members? It doesn't have type

annotation either. However, that's probably something best left to a separate proposal since it would affect private and public members alike.

# Aaron Gray (8 days ago)

On Wed, 8 Aug 2018 at 14:34, Ranando King <kingmph at gmail.com> wrote:

Did you see any similarity with my proposal-object-members rdking/proposal-object-members? It doesn't have type annotation either. However, that's probably something best left to a separate proposal since it would affect private and public members alike.

This looks excellent.

# Logan Smyth (8 days ago)

It might help if you could clarify how your proposal diverges from the class fields proposal that you linked to. From purely a syntactic view, ignoring the type annotations, I don't see an obvious difference, so it is hard to tell what your expectations are. You state "I have shown the idea of declaring subobject default value declarations.", but I can't actually tell what that means or what you intended to show. Is

defaults = {
  a: 1,
  b: 2
}

meant to create a property called defaults, or do something else?

# Aaron Gray (7 days ago)

On Fri, 10 Aug 2018 at 00:09, Logan Smyth <loganfsmyth at gmail.com> wrote:

It might help if you could clarify how your proposal diverges from the class fields proposal that you linked to. From purely a syntactic view, ignoring the type annotations, I don't see an obvious difference, so it is hard to tell what your expectations are. You state "I have shown the idea of declaring subobject default value declarations.", but I can't actually tell what that means or what you intended to show. Is

defaults = {
  a: 1,
  b: 2
}

meant to create a property called defaults, or do something else?

That and the syntax.

Aaron

# Logan Smyth (7 days ago)