Class data member declarations proposal idea

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Class data member declarations proposal idea

Aaron Gray-4
Hi,

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 https://github.com/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. https://github.com/codemix/flow-runtime


--
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and amateur computer scientist.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class data member declarations proposal idea

Waldemar Horwat
See this proposal, currently at stage 3:  https://github.com/tc39/proposal-class-fields

     Waldemar
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class data member declarations proposal idea

Isiah Meadows-2
In reply to this post by Aaron Gray-4
Check out the various class-related proposals at https://github.com/tc39/proposals. This is practically identical to the existing class field proposal, just mod the type annotation thing.

On Tue, Aug 7, 2018, 15:17 Aaron Gray <[hidden email]> wrote:
Hi,

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 https://github.com/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. https://github.com/codemix/flow-runtime


--
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and amateur computer scientist.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class data member declarations proposal idea

Aaron Gray-4
In reply to this post by Waldemar Horwat
On Tue, 7 Aug 2018 at 22:34, Waldemar Horwat <[hidden email]> wrote:
See this proposal, currently at stage 3:  https://github.com/tc39/proposal-class-fields


Yes I did reference the proposal my mail.
 
--
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and amateur computer scientist.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class data member declarations proposal idea

Ranando King
Did you see any similarity with my 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.

On Wed, Aug 8, 2018 at 7:50 AM Aaron Gray <[hidden email]> wrote:
On Tue, 7 Aug 2018 at 22:34, Waldemar Horwat <[hidden email]> wrote:
See this proposal, currently at stage 3:  https://github.com/tc39/proposal-class-fields


Yes I did reference the proposal my mail.
 
--
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and amateur computer scientist.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class data member declarations proposal idea

Aaron Gray-4
On Wed, 8 Aug 2018 at 14:34, Ranando King <[hidden email]> wrote:
Did you see any similarity with my 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.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class data member declarations proposal idea

Logan Smyth
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?


On Thu, Aug 9, 2018 at 3:47 PM, Aaron Gray <[hidden email]> wrote:
On Wed, 8 Aug 2018 at 14:34, Ranando King <[hidden email]> wrote:
Did you see any similarity with my 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.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class data member declarations proposal idea

Aaron Gray-4
On Fri, 10 Aug 2018 at 00:09, Logan Smyth <[hidden email]> 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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Class data member declarations proposal idea

Logan Smyth

On Fri, Aug 10, 2018 at 2:59 AM, Aaron Gray <[hidden email]> wrote:
On Fri, 10 Aug 2018 at 00:09, Logan Smyth <[hidden email]> 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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss