Classes as Sugar is now ready for discussion

Mark S. Miller erights at google.com
Thu Sep 9 16:26:01 PDT 2010


On Thu, Sep 9, 2010 at 10:37 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Sep 9, 2010, at 3:06 PM, Dirk Pranke wrote:
>
> As Brendan pointed out, the version evolution problem is nowhere near
> a solved issue in language design; the only approaches I know of that
> get close to it are the versioning of words in Forth and, depending on
> how you look at it, the dynamic code loading mechanisms of Erlang
> (and class loaders in Java). Insisting that we somehow come up with
> a mechanism to prevent conflicts seems like a pretty high bar; I'd
> like to hear more from people with such a view if that was indeed the
> blocking objection.
>
>
> That would be Waldemar :-).
>
> Again, I feel it is important to say that everyone in TC39 who spoke up
> averred that traits.js is a well-written library, compelling in many ways.
> However, here are some other issues with the library, which need to be
> restated or presented properly so that Waldemar is not painted as "sole
> spoiler":
>
> 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.
>
> 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).
>

Both the good and the bad news from the Bespin experience are exactly what
Tom & I expected in the absence of VM support.

Also, the duality of Object.create vs Traits.create accommodates traditional
vs high integrity quite well -- without AFAICT compromising either.


>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100909/8f8a49de/attachment-0001.html>


More information about the es-discuss mailing list