Classes: Moving away from object literal syntax

Herby Vojčík 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 mailing list