On Oct 4, 2011, at 12:16 AM, Alex Russell wrote: > 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?
Why are you trying to pick a fight with me? Waldemar just suggested following Tony Hoare's advice. Do you disagree or not? If not, why not? Anyway, don't personalize this to me. If you want to pick a personal fight, start with Waldemar. > Syntax or read barrier? Neither class syntax nor const inclusion (item 5) and the read barrier to detect use of a const instance variable before it has been initialized reached consensus. This has nothing to do with me or what I just wrote in the message to which you replied in a fight-y way. That we did not reach consensus is a fact. Please deal with it constructively. I am trying to. I see only two routes: agree quickly on syntax and semantics of some minimized classes design, or cut classes for now, which means pending new information, from ES6. > 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. Oliver liked declarative syntax that put instance variable declaration in the class body, not (in arbitrary control flow) in the constructor body. Oliver *and many others* do not like the current wiki'ed proposal's placement of public instance variable declarations in the constructor body. At the meeting we talked about trying to restrict where in that body such declarations might occur, and in what order with respect to super() or an initialized declaration boundary -- we failed to reach consensus on anything. > >> 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. Right -- we have no consensus, not on what Oliver and I (and I think Waldemar) want. We also do not have consensus on alterantive classes designs -- including for the public-declarations-in-constructor-body proposal you seem to be advancing here, by passive-aggressive impliciation. We Clearly Do Not Have Consensus On Classes. :-| /be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
