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. > I think this is the key issue. 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. 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. > > 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 > > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
