Classes as Sugar is now ready for discussion

Brendan Eich brendan at mozilla.com
Thu Sep 9 16:46:09 PDT 2010


On Sep 9, 2010, at 4:06 PM, Mark S. Miller wrote:

> 1. It's premature to standardize something so new. Again, the "Array extras" (map, filter, etc.) have been a de-facto standard for years, getters and setters for over a decade, bind-like library methods and JSON for quite a long while.
> 
> 2. I didn't know this till yesterday, but the Bespin (Skywriter, gag ;-) team at Mozilla tried using traits.js and had to stop, because it was consuming too much memory. I understand that this is from the pervasive use in the library of |this|-binding and copying to instance properties of all methods, along with other uses of closures. There is no prototypal sharing of method, or anything like vtables.
> 
> Some of this could be optimized by aggressively-optimizing VMs, but it carries a heavy intrinsic cost.
> 
> I think this is the key issue.

Points 1 and 3 are worth addressing, if you are game.


> Tom and I designed the traits library so that the expected common pattern of use would be easily optimizable by VMs, with no surprising intrinsic costs. If we missed the mark -- if there are indeed hidden costs lurking here that we missed -- that would be interesting.

You may recall the posts I made at the time:

https://mail.mozilla.org/pipermail/es-discuss/2010-February/010830.html
https://mail.mozilla.org/pipermail/es-discuss/2010-February/010832.html


> The "expected common pattern" which we expect to be optimizable needs to be stated clearly. Loosely, it is when trait composition is sufficiently statically analyzable that it can be expanded as if to a call to Trait.create with a literal property-descriptor-map argument. 
> 
> We also discussed that this is a good reason to couple VM support with special syntax -- so the special syntax can sugar only (primarily?) that pattern which can be handled efficiently. The full library would still be available for expressiveness of patterns that we don't expect VMs to optimize.

It's true, syntax can help optimizability (and usability). But we never heard a proposal and it's hard to make one up without worrying about how |this|-binding works in detail, e.g. Does a call go through a vtable in the case where the method is invoked via a property reference, otherwise a bound method object is created (for the escaping funarg case)?

And so on, in sufficient detail to see a path to trial implementation and interoperable observable semantics, including approximate or asymptotic cost models.

/be


> 3. The design, in trying to catch conflicts, copies this-bound methods, freezes objects, and avoids prototype-based delegation. Beyond the costs in 2, this makes for a harshly bright line between Object.create and Trait.create, and although it is cool that the two systems complement each other, more "traditional" JS hackers arguably want prototype-based delegation, even though it may carry a shadowing conflict risk down the road. Some JS hackers even want mutability, with spot-checks for conflicts instead of "for all/ever" guarantees.
> 
> These are not points we've discussed enough in committee, since we didn't talk about traits again since March. As noted, some details are news to me, but good to hear later instead of never.
> 
> Points 2 and 3 are related: traits.js aims at higher integrity, for robust composition, than many JS hackers prefer and would choose (from what I hear, now -- I'd be happy to hear stories of successful adoption of the traitsjs.org code to counter the Bespin experience).
> 
> A number of people, and I'm one of them having heard all the feedback so far (although I cited the costs listed in 2 on this list when the proposal was first posted), believe that this "integrity trade-off" should not be forced by blessing one fairly costly and near-extreme point in the trade-off space as a core language feature.
> 
> This gets back to point 1. It also relates to the recent objections to zero-inheritance "classes as sugar", which have high integrity but no inheritance.
> 
> /be
> 
> 
>> 
>> -- Dirk
>> 
>> On Thu, Sep 9, 2010 at 3:13 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
>>> There's no mistake that dedicated syntax for traits would help users and
>>> implementors alike. However, while I (or others) could definitely come up
>>> with a 'traits-as-sugar', or even a 'traits-as-a-new-value' proposal, that
>>> still wouldn't solve the version evolution problem associated with trait
>>> composition (or any other traditional inheritance mechanism). As long as
>>> this remains a deal-breaker, I don't think it's worth looking into
>>> alternative traits proposals.
>>> As Dave said, traits.js is out there for people to experiment with. Any
>>> feedback on usability issues of the design in its current form are highly
>>> appreciated.
>>> 2010/9/9 David Herman <dherman at mozilla.com>
>>>> 
>>>>> Agreed; perhaps my question was not clear. If there was a Traits-like
>>>>> proposal that did include new syntax, would you be against it because
>>>>> you can implement something similar as a library without needing new
>>>>> semantics, or would you be more inclined to reserve judgement until
>>>>> you could actually review a proposal and see what the proposed
>>>>> benefits were?
>>>> 
>>>> The latter (speaking for myself, of course).
>>>> 
>>>> Dave
>>>> 
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> _______________________________________________
> 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/20100909/ed19c18b/attachment.html>


More information about the es-discuss mailing list