Private Names and Methods

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Apr 6 15:57:15 PDT 2012


On Apr 6, 2012, at 2:57 PM, Axel Rauschmayer wrote:

> I was thinking about Allen’s
> 
>     class Sub extends mixin(Jane, Jack, Super) {
>     }
> 
> Which could have the following prototype chain.
> 
>     Sub -> Jane' -> Jack' -> Super.prototype
> 
> A method in a module that works like Prototype’s Object.extend(), but copies private properties should suffice.
> 
> Variations:
> - Copy Jane and Jack into the same object.
> - Use a class declaration to define the mixins Jane and Jack. Then the prototype chain is
>         Sub -> Jane.prototype' -> Jack.prototype' -> Super.prototype

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 -> 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. 


> 
> 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 contest of a meta-programable dynamic object system.


Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120406/1016c0db/attachment.html>


More information about the es-discuss mailing list