On Mon, Oct 3, 2011 at 12:26, Waldemar Horwat <walde...@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.

-- 
erik
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to