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). 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...@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 <dher...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >> >> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
