On Thu, Sep 9, 2010 at 10:37 PM, Brendan Eich <bren...@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...@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 > > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
