I noted some open issues on "Classes with Trait Composition"

Brendan Eich brendan at mozilla.com
Tue Jun 7 12:57:37 PDT 2011


On Jun 7, 2011, at 12:42 PM, Gavin Barraclough wrote:

> Brendan,
> 
> Out of interest was a C++/Java style constructor considered, with the constructor name matching the class name?

I'm not sure -- I wasn't in on the earlier design sessions among the champions. I know "new" was used, but if we are sugaring prototypal inheritance, we need something to create "constructor" in the prototype (which is where method definitions written directly in the class body bind their names).

Having some backstage magic wire up "constructor" is possible but then you have two names for the constructor. That is a wart.

The bigger issue is that doing this preempts use of "new" as a prototype property name (allowed by ES5).

So to keep things simple, express the prototypal machinery already in the language directly and explicitly, and avoid preempting "new", we've settled on "constructor".

The bigger issues with classes to close down include private instance variable syntax and semantics, and static method s&s. Some followup work is already under way here. We need to get this solid by the July TC39 meeting.

/be

> 
> cheers,
> Gavin.
> 
> 
> On May 16, 2011, at 8:02 AM, Brendan Eich wrote:
> 
>> On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote:
>> 
>>> On 16.05.2011 10:49, Brendan Eich wrote:
>>>> 
>>>> On May 15, 2011, at 10:01 PM, Brendan Eich wrote:
>>>> 
>>>>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
>>>>> 
>>>>> This looks pretty good at a glance, but it's a lot, and it's new.
>>>> 
>>>> Looking closer, I have to say something non-nit-picky that looks bad and smells like committee:
>>>> 
>>>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#inheritance
>>>> 
>>>> Two kinds of inheritance, depending on the dynamic type of the result of evaluating the //MemberExpression// on the right of ''extends''? That will be confusing.
>>>> 
>>>> Is the traits-composition way really needed in this proposal? If so, then please consider not abuse ''extends'' to mean ''compose'' depending on dynamic type of result of expression to its right.
>>>> 
>>> 
>>> Some simple examples of all use-cases would are needed I think.
>>> 
>>> Regarding `new` keyword for the constructor (aka initializer), after all, it als may be OK. E.g. Ruby uses `new` as exactly the method of a class -- Array.new, Object.new, etc. Though,  `constructor` is also good yeah.
>> 
>> My point is not to bikeshed, rather (a) to name existing prototype properties minimally, (b) to avoid preempting other names.
>> 
>> Good, bad, or in between, the prototypal pattern in JS for constructor C binds C.prototype.constructorr to C. It does not bind C.prototype.new.
>> 
>> 
>>> Regarding two inheritance types, I think better to make nevertheless one inheritance type -- linear (by prototype chain). And to make additionally small reusable code units -- mixins or traits -- no matter. Thus, of course if they will also be delegation-based and not just copy-own-properties, then we automatically get a sort of multiple inheritance.
>> 
>> Self has multiple prototypes and you can use them for all kinds of inheritance patterns.
>> 
>> Parents are Shared Parts...
>> 
>> Organizing programs without classes
>> 
>> 
>>> Delegation-based mixins though can be implemented as a library using proxies (example: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/mixin.js, implementation: https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/mixin.js, notice I also used Object.new :)).
>> 
>> Proxies are too costly, though. They always have a handler full of traps. The idea with classes is to capture prototypal inheritance as used today. The idea with traits is to make composition flexible, with fast failure on conflict and tools to rename around conflicts.
>> 
>> Putting classes and traitts together should be doable but it shouldn't use the same sytnax (extends) and it shouldn't require proxies.
>> 
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110607/abad793b/attachment.html>


More information about the es-discuss mailing list