Finding a "safety syntax" for classes

Russell Leggett russell.leggett at
Fri Mar 23 07:14:03 PDT 2012

On Fri, Mar 23, 2012 at 7:00 AM, Herby Vojčík <herby at> wrote:

> Andreas Rossberg wrote:
>> On 23 March 2012 08:42, Claus Reinke <claus.reinke at
>> <mailto:claus.reinke at talk21.**com <claus.reinke at>>> wrote:
>>    - would it make sense to name the constructor after the class
>>       (avoiding 'constructor' and 'new')?
>> -1.
>> I always considered this a bad choice of C++-derived class systems. It
>> violates Don't-repeat-yourself, and thus is annoying e.g. when you
>> rename things. It is less searchable and less readable locally, because
>> you have to take the name of the surrounding class into account to
>> decide what kind of declaration you are looking at. And it doesn't scale
>> to anonymous classes, in case these ever become an option for ES.
> Good point. ;-)
> The 'constructor' gets created anyway if classes are to be compatible with
> plain constructor functions semantics. That is big plus for 'constructor'
> (and big minus for 'new' since people may look for Class.prototype["new"}
> and not find it).
> I will repeat myself, I proposed this thing but no one reacted. It's
> short, does not clash as new mentioned before, and does not preclude
> constuctor magic in any way:
> class Class extends SuperClass {
>  @(params) { body } // constructor
>  @x(params) { body } // private-named method
>  y(params) { body } // plain method
> }
> Of course, this syntax is based on '@xxx' private name access pattern is
> also in the language - constructor is intentionally reusing this syntax,
> but with 'empty identifier' - as a special short construct to use for
> constructor. Reusing private name syntax is safe as to name clash, because
> it does not clash with property names (and using empty identifier, neither
> does clash with real private names).

I'm not sure if you're suggesting we add private name support for this
proposal, but that would be feature creep. If you are suggesting only @()
for constructor, then I think that would still be pretty confusing and
grawlixy. I suppose you could make the argument that the underlying
constructor itself is some private property, and therefore makes sense to
use @, but that seems like exposing internals on something that should be
straightforward. If that was not your intention, then I think it's even
more confusing because you're associating the constructor with something

- Russ

>  /Andreas
> Herby
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list