Sep 27 meeting notes

Waldemar Horwat waldemar at google.com
Mon Oct 3 12:26:25 PDT 2011


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.

     Waldemar


More information about the es-discuss mailing list