[Proxies] Refactoring prototype climbing in the spec

Allen Wirfs-Brock allen at wirfs-brock.com
Thu Nov 10 10:21:37 PST 2011


On Nov 10, 2011, at 9:03 AM, Tom Van Cutsem wrote:

> 2011/11/10 Allen Wirfs-Brock <allen at wirfs-brock.com>
> 
> On Nov 10, 2011, at 1:36 AM, Tom Van Cutsem wrote:
>> - Object.getProperty and Object.setProperty built-ins that call [[GetProperty]] and [[SetProperty]]
> 
> Also, to fully reify property manipulation I think we also need to factor [[Delete]] in a similar manner and provide an Object.deleteProperty built-in that calls the DeleteProperty abstraction operations.
> 
> I touch upon this in http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation#a_side_note_on_reflective_property_access (note that this stawman is still under construction)
> 
> the basic reason is that just like with Get/Put a handler may want to invoke the primitive behavior of Delete upon the target object without going through the delete operator (which could retrigger a trap).
> 
> Actually I was mistaken: the above quoted line should read:
>> - Object.getProperty and Object.setProperty built-ins that call the [[Get]] and [[Set]] methods
> 
> In other words: it's important that Object.getProperty(aProxy, name) triggers that proxy's "get" trap rather than performing the Object algorithm and calling the getOwnPropertyDescriptor trap.
> Otherwise, proxies would not compose well (think of a proxy p1 wrapping another proxy p2: if p1 forwards a property access to its target (p2), p2's "get" trap should be triggered).
> (+ we could end up with duplicated getOwnPropertyDescriptor calls, as pointed out by David earlier)
> 
> If the goal is to intentionally avoid proxy traps, one can write up the algorithm in Javascript itself (as I have done on the strawman page). But I think it's important that Object.getProperty does trigger proxy traps (if only for consistency: Object.getOwnPropertyDescriptor et al. also trigger proxy traps).

Yes, on further thought, I agree that Object getProperty should trigger the trap.

> 
> Regarding property deletion: if an object is implemented as a proxy, and you would want to delete a property from that object, I'm not sure why you would want to circumvent triggering the delete trap?

In http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation I'm exploring explicitly distinguishing the semants of obj.propName and obj[expression] such that an object can explicitly define its obj[expression] behaviors without using a Proxy (note that currently  by the time a Proxy is called, the distinction is already lost so even if you wanted to use a Proxy for this purpose they may not be adequate).  In many cases (including the default), the object-specific  "handler" for obj[expression] will delegate back to Object.getProperty/Object.setProperty (either directly or via a super call).  But note that it can do so via direct [ ] syntax, as that would loop.  This can actually all be modeled with a new Reference variant within the spec. that distinguishes . references from [ ] references.

However, I also need to account for the delete operator and distinguish delete obj.propName from delete obj[expression] .  This can be taken care of by the same reference extension (essentially References needs a delete "method").  A handler for deleting obj[expression]] may also want to delegate back to normal property deletion and for the same reason as for  obj[exper]  get/set handlers it can't directly use the syntactic form.  Instead it needs to call an Object.deleteProperty function.

BTW, rather than adding these methods to Object, I'm beginning to think it might be better to import them from a built-in reflection module.

>> - [[Get]] and [[Set]] methods on Objects that call [[GetProperty]] and [[SetProperty]]
>> - [[Get]] and [[Set]] methods on Proxies that trigger "get" and "set" traps
> 
> Yes, although I prefer to think of [[Get]] and [[Set]] consistently for both Proxy and "normal" objects.  They are polymorphic "traps" that dispatch to a handler that is determined by the nature of the object.  For native objects [[Get]] and [[Set]] dispatch to handlers that just call GetProperty or SetProperty
> 
> Do you mean that the direction you would like to go is to look at normal ES5 objects as proxies with a special, built-in handler?

Yes, exactly.  BTW, I think this was probably the intent of the originally internal methods and native+host objects design.

allen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111110/76769894/attachment-0001.html>


More information about the es-discuss mailing list