On Jun 16, 2011, at 9:15 AM, Mark S. Miller wrote: > > > On Thu, Jun 16, 2011 at 9:09 AM, David Bruant <[email protected]> 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: >> Le 16/06/2011 16:50, Tom Van Cutsem a écrit : >>> 2011/6/16 Mark S. Miller <[email protected]> >>> Ok good, I'll take you up on that. I propose that ES-next arrays differ >>> from ES5 arrays in that their 'length' property appears to be a >>> non-configurable accessor property. Clearly, that better reflects the way >>> Array's 'length' works anyway. Alternatively, if there's some problem with >>> that, I propose that array 'length' appears to be a configurable data >>> property that arrays nevertheless refuse to delete. Either way, proxies >>> would then be able to emulate them faithfully. >>> >>> This is also my feeling: part of the awkwardness in emulating array >>> "length" is definitely that we're trying to mimic the behavior of an >>> accessor property using a mutable data property. Would Mark's suggestion be >>> too radical a change? (note: I'm not arguing for this change on the grounds >>> of "it's too awkward to emulate using proxies". I'm arguing on the grounds >>> of "ES5 accessor properties seem to better describe the behavior of a >>> dynamic property such as array |length|"). >> In arrays, "length" affect numerical properties, but the opposite is also >> true. Should all numerical properties be considered as accessors then? >> (there is a little bit of bad faith here, because a valid implementation is >> possible with just "length" being an accessor. See [1]). >> >> Considering "length" as a data or accessor property is a secondary question >> in my opinion. The "magic" behavior is not at the property level but at the >> object level (even though it can be emulated at the property level). >> 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. > > 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? > > I do not believe so. The host object contract for configurable shows that the > only meaning it ever had in ES5 that one could count on is "this is not > guaranteed not to be magical". The proxy spec already allows the same > violations of the first two meanings you suggest: > * a proxy and a compliant ES5 host object may refuse to delete a configurable > property, and > * a proxy and a compliant ES5 host object may refuse an attempt to > reconfigure a configurable property. > > In summary, "configurable" was never a guarantee of anything. > "non-configurable" was the only state that came with guarantees. Let's not > weaken those.
I don't agree with this conclusion at all. There is a guarantee, it is just hard to know when it is applicable. There are three layers of the system invoked here: 1) The normal native object semantics as manifest in the basic native operations of the language: property put, property get, property delete, implicitly or declarative property create, property enumerate, etc. This is the level that most application code operates at. 2) The Object.* introspection semantics that provide information (attribute values) on and limited control of how individual properties will actually respond to the basic native object operations. 3) An intercession semantics that allows complete redefinition of the semantics of the basic object operations. This is the "magic" level that allows creation of things that aren't normal native objects. This level includes the mechanisms of Proxy, host objects, and any built-in object semantics that deviate from normal object semantics. For normal native objects there is a complete specification of the relationship between layer 1 and layer 2. For example, if you inspect a property's configurable attribute (a level to reflection operation) and see that its value is true you know that applying the delete operator to that property (a level 1 operation will succeed in deleting the property). Similarly if you use a reflective operation to set the configurable attribute of a property you know that applying a delete operation will fail. The root question here seems to be if and how level 3 is allowed to modify the standard semantic linkage between levels 1 and 2. Given that level 3 is permitted to make pretty much arbitrary changes to the level 1 semantics, I'm not sure that this is even a very meaningful question as the level 1/level 2 normal native object semantic coupling is dependent upon the normal level 1 semantics. ES5 tried to express some restrictions upon what host objects are allowed WRT the level 1-2 semantic linkage. Those restriction had no teeth and it isn't clear that they have had any impact. There were no such restrictions on additional implementation provided built-in objects. We are now talking about what restriction are imposed (and enforced) on Proxy based objects. Given the above view, it seems pointless to argument about placing level 3 constraints upon the value of the configurable attribute so that level 1 (or level 2) code can condition its behavior based upon its setting. What such code really want to know is whether an object is a native object and hence conforms to the standard level 1 and level 2 semantics or whether this is a magic level 3 defined object. In the latter case, no logic based upon the native object semantics will necessarily be valid. It seems that what such code really needs is the ability to test whether or not an object is a magic object. If not, it can depend upon the native object semantics for both level 1 and level 2. If it is magic, the client code might refuse to deal with the object or it might attempt to further identify the specific spell that the object is under in order to understand how it will behave. Allen > > > > -- > Cheers, > --MarkM > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
