Class data member declarations proposal idea
See this proposal, currently at stage 3: tc39/proposal-class-fields
Waldemar
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.
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.
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.
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.
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 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
That and the syntax.
The syntax snippet you posted is identical to what is already supported by the class fields proposal alongside Flowtype. You can see this with Babel: babeljs.io/repl/#?babili=false&browsers=&build=&builtIns=false&spec=false&loose=true&code_lz=MYGwhgzhAEAa0FMAeAXBA7AJjAmtA3gFDTTAD26EKATgK7ApnUAUAlAdBLQA4IvsBfYtEwIAZmFogUMALwFhJMAC5oARgA0i6ACNVAJmFCSSaKoCS6NAHM-0eQGZhYALIIUACzKY2HIQKA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&sourceType=module&lineWrap=true&presets=react%2Cstage-0&prettier=false&targets=&version=6.26.0&envVersion=1.6.2
It would help to clarify what is different about how you envision fields to behave.
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 :-
syntax modifications :-
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
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180807/47d1df3b/attachment.html>