Sep 27 meeting notes

[Brendan Eich]

On Oct 1, 2011, at 4:23 AM, Waldemar Horwat wrote:

> On 09/30/2011 06:51 PM, Brendan Eich wrote:
>> On Oct 1, 2011, at 3:34 AM, Waldemar Horwat wrote:
>> 
>>> On 09/30/2011 05:07 PM, Brendan Eich wrote:
>>>>> On 09/30/2011 04:37 PM, Brendan Eich wrote:
>>>>>> since we haven't come up with a way to do 2 and 5 that works,
>>>> 
>>>> We can add these later  ...
>>> 
>>> Those two statements you made are in direct contradiction.
>> 
>> No, not logically -- you would have to assume something more, like for instance:
>> 
>>>  If there were a way to do it that's satisfactory to the group, we would have found it by now.
>> 
>> and I didn't make this third statement. It's your assumption.
> 
> So you're saying we should keep looking?

I'm saying the same thing Arv said: we can have useful minimal classes now and not be hostile to const properties in the future, added by some means (possibly already discussed, e.g. the read barrier).


> I feel like you're playing word games.  Being satisfactory to the group is an obvious and implied requirement.

Who is playing games? You said my two statements contradict each other but they do not. You assume or assert that we can't do minimal classes without going down a bad path for const properties later, but that's not self-evident.

If you could say why minimal classes are future-hostile to const properties, that would help.


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


> You haven't demonstrated any approach which "we can add later" that would be acceptable to the group.  On the contrary, experience from the past two meetings suggests that it does not exist.

I don't have to make the future come true now to believe that minimal classes are useful and not future-hostile. You haven't demonstrated that minimal classes are not useful enough to be worth doing without const properties.

"Classes desugared by hand" have been done for years in JS without any kind of non-writable property definition primitive, let alone one you can't read as undefined before it has been initialized. These are use-cases for classes as sugar. Why can't we specify classes as sugar for these use-cases and defer const properties?

I'm not going to keep going around and around on this whole argument, though. If, even without some kind of evidence or demonstration, you're convinced that minimal classes are future-hostile, I give -- we can defer classes entirely and get on with other work.

/be