Classes: Moving away from object literal syntax
herby at mailbox.sk
Wed Mar 21 10:29:21 PDT 2012
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.
More information about the es-discuss