Private Names and Methods

Allen Wirfs-Brock allen at wirfs-brock.com
Sat Apr 7 14:20:42 PDT 2012


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

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


More information about the es-discuss mailing list