> 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.prototype -> 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.prototype -> 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.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?
>> 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.
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?)
--
Dr. Axel Rauschmayer
[email protected]
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
