Sep 27 meeting notes

Brendan Eich brendan at
Mon Oct 3 17:21:23 PDT 2011

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. :-|


More information about the es-discuss mailing list