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 <[email protected]> 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 <[email protected]> >>>> >>>>> 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 >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Cheers, > --MarkM > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
