Classes: Moving away from object literal syntax
AFAICT this is a small variation on what was discussed last summer. What am I missing?
Nothing, the changes are minor: It’s just not based on object literal syntax, any more (= instead of : and ; instead of ,). And instead of private { foo }, there is now private foo;
Yeah, they are pushing it hardly this way. It seems inevitable... I am willing to accept it, but I'd like to have a clear mapping from object initializer components into class body components - if it is there, I don't care about syntax (the main concern for me is, that if certain things are possible in object initializer, they should be either:
- known to be banned in class, or
- straightforwardly mappable
That brings the question: what about static block? I think it should have exactly same rules as the basic class block (sans possibility having its own nested static block). That is, what about that const? Is data allowed in static (const-only or let as well) but not in class; or is it possible in class as well (which means, it defines shared data thing in prototype)?
On Mar 21, 2012, at 12:42 , Herby Vojčík wrote:
Yeah, they are pushing it hardly this way. It seems inevitable... I am willing to accept it, but I'd like to have a clear mapping from object initializer components into class body components - if it is there, I don't care about syntax (the main concern for me is, that if certain things are possible in object initializer, they should be either:
- known to be banned in class, or
- straightforwardly mappable
That brings the question: what about static block? I think it should have exactly same rules as the basic class block (sans possibility having its own nested static block). That is, what about that const? Is data allowed in static (const-only or let as well) but not in class; or is it possible in class as well (which means, it defines shared data thing in prototype)?
“I think it should have exactly same rules as the basic class block” – I agree 100%.
Const is indeed tricky – I always liked the # sigil proposal for object literals, but I don’t think they can work with this syntax. Const only means non-writable and makes just as much sense for methods. Shared data (as in “properties whose values are not functions”) should not be allowed for the prototype, because it makes no sense.
Axel Rauschmayer wrote:
On Mar 21, 2012, at 12:42 , Herby Vojčík wrote:
Yeah, they are pushing it hardly this way. It seems inevitable... I am willing to accept it, but I'd like to have a clear mapping from object initializer components into class body components - if it is there, I don't care about syntax (the main concern for me is, that if certain things are possible in object initializer, they should be either:
- known to be banned in class, or
- straightforwardly mappable
That brings the question: what about static block? I think it should have exactly same rules as the basic class block (sans possibility having its own nested static block). That is, what about that const? Is data allowed in static (const-only or let as well) but not in class; or is it possible in class as well (which means, it defines shared data thing in prototype)?
“I think it should have exactly same rules as the basic class block” – I agree 100%.
Const is indeed tricky – I always liked the # sigil proposal for object literals, but I don’t think they can work with this syntax. Const only means non-writable and makes just as much sense for methods. Shared data (as in “properties whose values are not functions”) should not be allowed for the prototype, because it makes no sense.
But then you are negating yourself - if you allow it for static but not for prototype, then they are not 100% same... if I can add shared data in static, I should be able to add it to prototype - or vice versa, I can not add it to either one.
“I think it should have exactly same rules as the basic class block” – I agree 100%.
But then you are negating yourself - if you allow it for static but not for prototype, then they are not 100% same... if I can add shared data in static, I should be able to add it to prototype - or vice versa, I can not add it to either one.
OK, to be completely precise: The same rules should apply for both, with the exception of non-function-valued properties which are not allowed for prototypes.
Axel Rauschmayer wrote:
“I think it should have exactly same rules as the basic class block” – I agree 100%.
But then you are negating yourself - if you allow it for static but not for prototype, then they are not 100% same... if I can add shared data in static, I should be able to add it to prototype - or vice versa, I can not add it to either one.
OK, to be completely precise: The same rules should apply for both, with the exception of non-function-valued properties which are not allowed for prototypes.
Then my opinion is against this proposal. It's too artificial, strange and maybe even nannyish restriction, imo.
Herby Vojčík wrote:
That brings the question: what about static block? I think it should have exactly same rules as the basic class block (sans possibility having its own nested static block). That is, what about that const? Is data allowed in static (const-only or let as well) but not in class; or is it possible in class as well (which means, it defines shared data thing in prototype)?
What about statics? Maybe.
What about const? Later.
Protected? Later.
Bell #47, Whistle #99: Later.
If we keep piling features and bells and whistles on, classes will never happen. I am 100% sure of this.
We could have had minimal classes in ES6 last summer, but for unfalsifiable future-proofing concerns about use-before-init re: const and guards. We may still reach consensus on minimal classes. Never on maximal classes.
On Wed, Mar 21, 2012 at 1:49 PM, Brendan Eich <brendan at mozilla.org> wrote:
Herby Vojčík wrote:
That brings the question: what about static block? I think it should have exactly same rules as the basic class block (sans possibility having its own nested static block). That is, what about that const? Is data allowed in static (const-only or let as well) but not in class; or is it possible in class as well (which means, it defines shared data thing in prototype)?
What about statics? Maybe.
What about const? Later.
Protected? Later.
Bell #47, Whistle #99: Later.
If we keep piling features and bells and whistles on, classes will never happen. I am 100% sure of this.
We could have had minimal classes in ES6 last summer, but for unfalsifiable future-proofing concerns about use-before-init re: const and guards. We may still reach consensus on minimal classes. Never on maximal classes.
Speaking of which - curious to see your take on the "safety syntax" thread.
Brendan Eich wrote:
Herby Vojčík wrote:
That brings the question: what about static block? I think it should have exactly same rules as the basic class block (sans possibility having its own nested static block). That is, what about that const? Is data allowed in static (const-only or let as well) but not in class; or is it possible in class as well (which means, it defines shared data thing in prototype)?
What about statics? Maybe.
What about const? Later.
Protected? Later.
Bell #47, Whistle #99: Later.
No, no, I do not want to argue in adding this or that. I agree on Russell's minimal classes.
I was just saying that it there should either be both or none of the class/static block of Alex's proposal should allow consts/lets. I am happy with none.
Makes sense. I removed the static block. I only faintly remember David’s proposal, but I think it’s almost like his “minimal classes” now – IMO a good thing.
Brendan argued that if you restrict in class declarations what you can do syntactically then basing their syntax on object literals will confuse people. I agree. Based on that and on a recent proposal for a non-braces private syntax, I’ve updated my class declaration proposal:
gist.github.com/1336846