On Jul 18, 2013, at 12:56 AM, Andreas Rossberg wrote:
> On 18 July 2013 01:09, Brendan Eich <bren...@mozilla.com> wrote:
>> Brandon Benvie wrote:
>>>
>>> On 7/17/2013 4:02 PM, Brandon Benvie wrote:
>>>>
>>>> And this is how it currently works in the V8 implementation. The first
>>>> thing I did testing it looked like:
>>>>
>>>> var s = new Symbol();
>>>> var x = {};
>>>> x[s] = 'test';
>>>>
>>>> I was surprised to find that this threw an error instead of doing the (to
>>>> me) obvious thing.
>>>
>>> (And to clarify, it throws on line 3, not line 1)
>>
>> This is nuts.
>
> May I humbly remind you that we explicitly discussed and decided this
> at the March meeting? I actually would have preferred if 'new Symbol'
> worked, and that was what V8 implemented before the meeting.
from the minutes:
AWB: I can define the Symbol[@@create] to throw
that means 'new Symbol' would throw.
But, as I mentioned in another message, I actually don't see in the minutes a
record of consensus one way or another regarding Symbol wrapper objects. I do
see push back against them and by I personally went away believing that we
agreed to try primitive symbols with no wrapper objects. If you look at the
Rev15 (May 2013) spec. draft the timestamp on the edits to introduce those
changes is March 18, 2013. So, I made those changes 4 days after the meeting
discussion and presumably with a fresh recollection of what transpired.
>
> Seriously, all this discussion is about breaking the March consensus.
> I find it rather irritating that some seem surprised about decisions
> they actively had their part in. Moreover, I find it unacceptable when
> the editor decides to break consensus single-handedly and implements
> it without notice, let alone discussion.
Unfortunately, we don't even agree upon the details of the consensus. These
consensus agreements at meetings are important, and I always try to get them
into the spec. draft as soon as possible. However, they are typically made in
the context of a relatively short "debate" where it is impossible for everybody
to explore and understand all the deep implications of a decision. Sometimes
we reach a consensus that latter proves to be problematic.
I have to take the result of those decisions and try to make them work in the
spec. and implementors should be trying to make them work in their engines. I
immediately incorporated the my understanding of the consensus into what was
ultimately released as the May draft. After that I started to routinely
discover numerous additional special cases in the spec. where primitive symbols
had to be explicitly accounted for and also discovered that it was something
that I was having to consider (or was forgetting to consider) as I added new
material to the spec. My conclusion, was that primitive symbols without
wrappers wasn't going to work.
I know I informally talked about this with several people. I reverted symbol to
being an exotic object May 29 shortly after getting back from the May TC39
meeting so something that came out of that meeting pushed me over the edge
towards reverting. I think it probably was things I ran into while changing
function call to use [[Invoke]].
At a meta level, I need to keep moving forward on the spec. or it will never be
completed. We seldom are able to definitively resolve issues on es-discuss and
I can't let myself get blocked for up to two months waiting for a TC39 meeting.
So I have to make make informed guesses about ultimate outcomes and use them
in my working drafts so I can move forward with a reasonably self-consistent
spec. Every thing in the draft spec is subject to (and needs) serious review
by TC39 members. As I say quite often, nothing in the spec. if final until the
entire thing is approved by TC39. (BTW, I really appreciate the stream of good
feedback continue to get from the V8 team via bugs.ecmascript.org).
In this particular case, I guessed that we were going to ultimately either go
back to Symbols as objects or to introduce wrapper objects for primitive
Symbols. So, I had basically three choices: 1) keep going with special case
handling of primitive symbols scattered through out the spec. 2) Revert to a
centralized definition of exotic symbol objects, 3) add symbol wrappers.
option 1 was the maintenance nightmare I was trying to recover from. I
believed there was strong opposition to adding additional wrapper objects, so I
didn't want to push a Symbol wrapper into the spec. yet. But it turns out that
option 2, was also a reasonable place for moving to option 3 if we decided to
go that route (both option 2&3 eliminates most of the special case handling).
So, that's where we stand today. I'm betting that TC39 will ultimately decide
on either symbols as exotic objects or primitive symbols with wrappers. The
current state of the spec. makes it easy for me to go either direction.
allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
