On Fri, Mar 23, 2012 at 7:00 AM, Herby Vojčík <[email protected]> wrote:
> > > Andreas Rossberg wrote: > >> On 23 March 2012 08:42, Claus Reinke <[email protected] >> <mailto:claus.reinke@talk21.**com <[email protected]>>> 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 > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
