Re: Configurable, writable "const" values?

I can't say I recall things being the way they are for any good reason, 
my guess is that it was an oversight back in the day that went unnoticed 
until now. I'd be happy to change Firefox to have constant constants. :)

On 12/01/2010 02:27 PM, Brendan Eich wrote:
> Constants should be constant. Two thumbs up on that.
>
> Not sure why we and IE do what we do. My memory fails me (this was well after my DOM level 0 creating days). Johnny Stenback may recall.
>
> /be
>
> On Dec 1, 2010, at 1:00 PM, Maciej Stachowiak wrote:
>
>> On Dec 1, 2010, at 12:32 PM, Travis Leithead wrote:
>>
>>> I was reviewing browser Interop for the following scenario, and want to get your take on the matter (because some recent W3C test submissions are exercising these assumptions and IE is considering changing our implementation):
>>>
>>> var original = Node.ELEMENT_NODE;
>>> Node.ELEMENT_NODE = "ten";
>>> var check = Node.ELEMENT_NODE;
>>> if (original !== check)
>>>    alert("const properties aren't constant");
>>> else
>>>    alert("const properties can't be written");
>>>
>>>
>>> Tested__      Result__
>>> WebIDL        not writable
>>> Opera         not writable
>>> IE9           writable
>>> FF4           writable
>>> Chrome7       not writable
>>> Safari5       not writable
>>>
>>> Any objections if IE9 changes to not writable? I presume FF would also eventually change? Is there a web compatibility reason for not doing this?
>>
>> I don't think there is a web compatibility constraint here. Safari has had the "not writable" behavior for a long time. I expect the other way does not have a problem either. So we should pick what is more sensible as the standard behavior. I think making constants constant is more sensible. I think we'd be open to changing WebKit's behavior if we come to consensus that the writable way is better.
>>
>> Regards,
>> Maciej
>>
>>
>

Received on Thursday, 2 December 2010 11:56:09 UTC