On Jun 16, 2011, at 9:09 AM, David Bruant wrote:

> Le 16/06/2011 17:46, Mark S. Miller a écrit :
>> 
>> On Thu, Jun 16, 2011 at 8:29 AM, David Bruant <[email protected]> wrote:
>> 
>> The question raised by Mark is: "should objects with noticeable custom 
>> internal method (array, host objects, proxies...) be allowed to prentend 
>> having data property even if some logic is triggered under the hood?".
>> 
>> Almost, and thanks for trying to summarize. My question is
>> 
>>   "Should ... be allowed to pretend having a *non-configurable* data 
>> property ...?"
>> 
>> A perfectly fine answer to the array.length issue is to have length be a 
>> configurable data property so long as it needs to operate in a magical 
>> manner. For all such problematic magical behavior, we should likewise report 
>> the property as configurable so long as it needs to operate in a magical 
>> manner.
> Currently, the "configurable" attributes has two meanings. At the same time 
> it tells who whether or not you can delete the property and whether or not 
> you can reconfigure (call to Object.defineProperty) your property. If I 
> understand well, you would like it also to tell whether the property is 
> magical or not.

Implementations need the no-delete aspect. We should not change that for Array 
length.

Freezing length is another use-case not to break, of course. No one disagrees 
there (we just have a SpiderMonkey bug to fix).


> If we are at a point where we'd break Object.defineProperty return values, 
> shouldn't we add new keywords rather than adding semantics to current 
> attribute keywords?

We should have no more attribute "keywords" in property descriptors than we 
need to model the semantics we wish to reflect on via Object.* APIs and 
intercede in via proxies. Do we really want to split "DontDelete" back out of 
"configurable"?

/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to