On Apr 6, 2012, at 4:11 PM, Axel Rauschmayer wrote: >> ... >> I think there is another approach that doesn't require copying. Use a proxy >> to define a synthetic prototype object that delegates to one or more mixin >> providers: >> >> Sub.prototype -> synthesized-mixin-delegator-> Super.prototype >> | | >> V V >> Jane Jack >> >> This is off-the-cuff so I haven't worked out the details but I think it >> almost works. I think it will work for string-keyed properties. >> Unfortunately, as currently specified it won't work for private name >> properties because the proxy traps that would need to do the delegated >> sideways property lookups are not passed the actual private name object. >> Instead they are passed a surrogate that can be matched against a known >> private name but which can't be used for a direct property access. There >> might be ways to fix that which still don't expose the actual private name >> to misuse. For example, perhaps a private name surrogate could expose a >> method that does a property lookup using actual private name without >> exposing the actual name. The security focused guys would probably have to >> tell us whether they could live with that additional exposure. > > [Quick aside: I forgot to write Sub.prototype, added above; object exemplars > make this less error-prone] > > With either approach, I wonder what the performance implications are. How > does one let the engine know, statically, what the prototype chain will be?
Proxy delegated property lookups can still be cached, as long as there is a reasonable way to invalidate the caches when the delegated property mapping changes. Modern engines presumably depend upon the (relatively) immutable nature of prototype chains and some sort of internal notification when the properties of a cached prototype object are modified. My scheme gives ES code in proxies control of the property lookup process so it would probably be necessarily to provide a mechanism that could be used by a lookup delegator object to announce its property mapping has changed and hence that any engine-level caches should be invalidated. There would definite design work requried to enable this, but it is something I have seem work in implementations of other languages. > > >>> Quoting Brendan: >>>> Including the private-named properties? That would be bad for integrity: >>>> Alice can't give Bob an object-as-capability where the private names stay >>>> private. Bob can extract them via this hypothetical spread-in-braces and >>>> then abuse them (e.g. to brand a counterfeit object and fool Carol into >>>> thinking it was from Alice). >> >> This has always been my issue with the integrity constraints that have been >> specified for private names. They really get in the way of the >> meta-programming. You can have a hight integrity or you can have rich >> meta-programming. It isn't clear to me that you can have both at the same >> time. >>> >>> I don’t see how that can be avoided. One could have two kinds of private >>> names: High-integrity ones and copy-able ones. >> >> That was the rationale behind >> http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects#possible_visibility_flag >> . This is something that I pushed quite hard for a while but it didn't >> seem to get a lot of traction. One reason, that I have kind of given up on >> it is that I don't think many programmer would actually code something like: >> >> const methodName = name.create("printName",true); >> >> to define their meta programmable private names. >> >> However, if we support >> private foo; //pretty much means: const foo=name.create("foo") >> >> then maybe it wouldn't be such a leap to also support: >> protected bar; //pretty much means: const bar-name.create("bar",true) >> >> In other words, protected gives you a private name that doesn't have the >> integrity constraints. This is actually not an unreasonable understanding >> of "protected" in the context of a meta-programable dynamic object system. > > How often does one write high-integrity objects? I suspect that only > specialists would want to use name.create("printName",true). Everyone else > uses `private`. (Right?) As I described it above, I would expect anyone doing classic inheritance based implementation reuse or use any meta-programming based frameworks would want to use 'protected'. Anyone who was primarily concerned about high-integrity would want to use 'private' Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
