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