Finding a "safety syntax" for classes

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


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

>
>
> Andreas Rossberg wrote:
>
>> On 23 March 2012 08:42, Claus Reinke <claus.reinke at talk21.com
>> <mailto:claus.reinke at talk21.**com <claus.reinke at talk21.com>>> 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
private.

- Russ


>
>  /Andreas
>>
>
> Herby
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120323/c69ee32e/attachment-0001.html>


More information about the es-discuss mailing list