July 26, 2012 TC39 Meeting Notes

David Bruant bruant.d at gmail.com
Sat Jul 28 03:54:29 PDT 2012


Le 28/07/2012 01:58, Rick Waldron a écrit :
> # July 26 2012 Meeting Notes
>
> # getPrototypeOf trap
>
> TVC: (introduction)
>
> __proto__ writable destroys invariant that [[Prototype]] link is stable
>
> Frozen objects should continue to have stable prototype chain
Frozen objects should continue to have stable [[prototype]]. You can't
guarantee for the entire chain.

> getPrototypeOf trap result should be consistent wth target object's proto
>
> MM: if the proto can be changed, the proxy should…?
>
> TVC: spec interceptable [[Prototype]]
> [[Prototype]] is currently an internal prop
> Would need to become internal accessor prop or split into [[GetProto]]
> / [[SetProto]]
> [[GetProto]] / [[SetProto]] would trigger traps for proxies
>
> AWB/BE: This is good
>
> YK: Do we want an analogous setPrototypeOf trap?
>
> TVC: Yes
This is inconsistant with below...

> AWB: If you have capability to set prototype ?
>
> TVC: proxy.__proto__ should just trigger the proxy's get trap
>
> var p = Proxy(target, handler)
>
> p.__proto__ // => handler.get(target, "__proto__", p)
> p.__proto__ = x // => handler.set(target, "__proto__", x, p)
If there is a setPrototypeOf trap as said above, it should be
handler.setPrototypeOf, no?

>> Trapping instanceof
>
> Function [[HasInstance]]
>
> x instanceof Global answering true if x and Global live in separate
> frames/windows
>
> var fp = Proxy(targetFunction, handler);
>
> x instanceof fp // handler.hasInstance(targetFunction, x)
>
>
> MM: Explains concerns originally raised on es-discuss list by David
> Bruant, but shows the cap-leak is tolerable
I'm interested in the demonstration :-)

>>
> DH: if hasInstance private name on instanceof RHS...
>
> MM: What Object.prototype does private name inherit from?
I assume s/Object.prototype/[[Prototype]], here?

> AWB: Probably null
>
> BE: the E4X any (*) name had null proto in SpiderMonkey, was true
> singleton in VM
>
> AWB: functions have home context, but no reason for objects to
>
> DH: this is a new idea of value that is not really any object
>
> OH: if it has no properties and no prototype
>
> BE: cannot be forged.
>
> Discussion about unforgeability.
>
> DH: Trapping instanceof use case
Does this line mean that DH asked for the use case? questioned it?
reminded it?
How did it relate to this discussion?

> Trapping Object.isExtensible
>
> Currently Object.isExtensible doesnt trap same for isSealed isFrozen
>
> var p = Proxy(target, handler)
>
> Object.isExtensible( p ) => Object.isExtensible
Are there new traps here? The conclusion of this part is hard to understand.

> Direct Proxies: "internal" properties
>
> Issue raised by Jason Orendorff; auto unwrapping is dangerous if
> built-in methods return non-primitive values
>
> Case:
>
> var arr = [o1, o2, o3];
> var it = arr.iterator();
>
> var membraneP = wrap(it);
>
> it.next.call(membraneP)
>
> Solution (?)
>
> Instead of auto-unwrapping, delegate to a nativeCall trap (which
> auto-unwraps by default)
I don't understand this use case and the problem that comes with it. Is
it specific to generators?


> # Proxies and private names
> (...)
> DH: so name.public === name?
>
> MM: I like that
>
> MM: are unique names in?
>
> DH: I think so
If they are, the .public part of private names could be retired with the
following setting:
* Private names don't trigger proxy traps call and are not be
reflectable at all. This is practically equivalent to calling a trap
with a useless public counterpart from the caller perspective. From the
proxy perspective, since the public part is useless, being called or not
sounds like it would be more or less equivalent.
* Unique names would be trapped and passed as unchanged as argument to
the trap (actually since name.public === name, passing the unique name
or its public counterpart is equivalent). If the proxy wants the unique
name not to be accessed, it cannot remove it from getOwnPropertyNames
trap result. So proxies can emulate their own private names.


> BE: are they actually distinguishable?
>
> MM: have to be if name.public === name or name.public !== name distinction
>
> DH: (named) boolean flag to Name constructor
If we have private and unique names, we might as well have 2
constructors : PrivateName and UniqueName. I find that more readable
than "new Name(true)".

> DH: do we have some way of reflecting unique names?
>
> TVC: Object.getNames() ?
>
> DH: ugh...
>
> AWB: maybe a flag to Object.getOwnPropertyNames({ unique: true })
>
> BE (editing notes): flags to methods are an API design anti-pattern
What's the conclusion of this part?

David


More information about the es-discuss mailing list