Direct proxies update
bruant.d at gmail.com
Thu Nov 24 15:50:39 PST 2011
Le 24/11/2011 22:11, Tom Van Cutsem a écrit :
> 2011/11/24 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
> freeze/seal/preventExtensions: For this particular case, I do not
> want to capture which function was called, but rather the
> intention of the programmer to set [[Extensible]] to false. If the
> proxy API does not provide a unique trap this particular
> operation, I have no way to create this unique trap myself. This
> can be annoying if another built-in sets [[Extensible]] to false.
> Even if my handler is a proxy, I can't know if the new trap is
> going to set [[Extensible]] to false.
> Not sure what you're after here. During the meeting, we reverted from
> protect(op) to splitting back into three traps as that allows freeze
> and seal to be turned into derived traps (in the virtual handler API).
> Also, AFAICT there is no built-in other than
> Object.preventExtensions/freeze/seal that sets [[Extensible]] to
> false. When using the VirtualHandler, you only need to override
> preventExtensions as freeze and seal depend on it.
> enumerate/keys/getOwnPropertyNames: It could be an idea to merge
> these as well (maybe not enumerate which traverses the prototype?)
> into one trap with an argument.
> Or maybe 2 traps: one dedicated to enumeration of own properties,
> one for proto-climbing properties.
> Our choice was to move away from grouping traps in this way. It's more
> consistent (no irregularities in the API), and in cases where you do
> want to distinguish between the two, it's a bit cleaner to separate it
> out into two methods rather than switching on the string.
I've been thinking about it more and the fact that derived traps are
reintroduced makes the choice of splitting traps (both for
[[Extensible]]:false and enumeration) a good choice. I hadn't ingested
all the new things entirely, but it all makes sense now.
>> I put my own notes on the discussion of direct proxies at the
>> meeting on the old strawman page:
>> Work in progress:
>> - Definition of a built-in handler that enables proxy handlers to
>> still inherit all derived trap implementations, as suggested at
>> the meeting:
> In the non-normative implementation, there is no import of the
> @reflect module (but it's used).
> Actually, the goal is for VirtualHandler and that implementation to be
> part of the @reflect module itself.
> This is a nice pattern: get, set, enumerate and has (all the traps
> that can be invoked on proxies-as-prototypes) apply the corresponding
> Reflect operation on the proxy's own prototype if the operation needs
> to proceed up the prototype chain.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss