On Oct 3, 2011, at 9:57 PM, Brendan Eich wrote: > On Oct 3, 2011, at 8:26 PM, Waldemar Horwat wrote: > >> On 09/30/2011 08:43 PM, Brendan Eich wrote: >>> On Oct 1, 2011, at 5:24 AM, Brendan Eich wrote: >>> >>>> On Oct 1, 2011, at 4:23 AM, Waldemar Horwat wrote: >>>> >>>>> There are lots of ways to do classes that satisfy all of 2-5. However, >>>>> it doesn't matter if those exist if those solutions are not acceptable to >>>>> the group. >>>> >>>> I know, I was ok with a read barrier for properties to enforce a temporal >>>> dead zone for const properties. Others were not ok with whatever overhead >>>> that might add to all property reads. >>>> >>>> But who says we need to solve 5 now? A number of us are saying we can >>>> defer it. >>> >>> And here's how this might then play out: some of us who do value const >>> properties prototype them as an extension to minimal classes, and we >>> demonstrate in fast VMs that the read barrier cost is negligible. The rest >>> of the group is convinced, and we add const properties later (next edition, >>> this edition if in time, doesn't matter). >>> >>> By insisting on solving all of 2-5 up front, when demonstration of >>> low-enough cost imposed by implementation of 5 is required by some in the >>> group, you guarantee no classes. By letting minimal classes proceed, you >>> might get const properties too. >>> >>> I can't guarantee this, but I can guarantee if we keep going in circles >>> we'll have no classes. >>> >>> You might argue that implementors can prototype solutions for 2-5 already, >>> but I think no one will risk it without more consensus in the committee. So >>> even if minimal classes is just an agreement for implementors, it would >>> help us get to consensus on the solution for 5. Does this make sense? >> >> Given that the choice seems to be between doing potentially future-hostile >> classes (where we'd bemoan the water under the bridge when trying to solve >> 2-6) and omitting classes altogether, C.A.R. Hoare's advice (as quoted by >> Bill Frantz) to defer classes would be the wiser thing to do. The standard >> is not a place for poorly understood features. > > I agree. > > If we had agreed on the read barrier, I think we would probably have > consensus on classes. It's interesting that Oliver (Apple) and I (at least, > among Mozillans) agreed.
So you're throwing out things on which basis? Syntax or read barrier? We got mild push-back from MSFT on complexity WRT read barrier. Others seemed to be OK with it. Oliver didn't like the declarative syntax. > Other implementations were not represented in my view. Take this for what > it's worth. Will feel free to take it as "not the consensus view" then. Regards _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
