Sep 27 meeting notes
erik.arvidsson at gmail.com
Mon Oct 3 15:43:10 PDT 2011
On Mon, Oct 3, 2011 at 12:26, Waldemar Horwat <waldemar at google.com> 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 and that is why I'm arguing for the even simpler classes proposal.
By not providing syntax we are continuing to encourage a million
incompatible "class" libraries.
More information about the es-discuss