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_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
