Apologies in advance for the length...
> A huge share of this complexity has been removed in recent discussions
> [1]. Conclusions seem to have reach consensus on es-discuss, but nothing
> has been officially accepted by TC39
>
As I understand it, the solution arrived at was to provide a (possibly
updatable) collection of private name objects to the Proxy constructor and
let the engine take care of the details. That sounds good, and good work!
What do you mean? Private name allow to do mixins without collision. It
> seems to reduce the complexity than increasing it in my opinion.
>
Unique (non-private) names offer mixins without collisions. But any
general mixin utility will fail if the source object relies on privately
named methods for its functionality:
// Create a private name
let privateMethodName = new Name();
// Create a "class" that naively defines and uses a privately-named
method
function A() {}
A.prototype.doSomething = function() { this[privateMethodName](); };
A.prototype[privateMethodName] = function() {};
// Create another "class"
function B() {}
// Attempt to mix A's functionality into B using a library function
mixin(A, B);
// Fails: privateMethodName is undefined
new B().doSomething();
Neither the destination object nor the library function "mixin" has access
to the private name, and therefore the privately named method will not get
copied to the destination object, and the mixin will fail.
Clearly the solution above would be to use a unique name, instead of a
private name. But that begs the question: why do we need private, secured
names at all? They complicate the object model without a compelling use
case, as far as I can tell. If there are use cases, let's see them.
In any situation where you want to *really* secure access to data or code,
the ergonomics of your code is going to be the least of your worries.
Security is just generally difficult, and that "soft-tissue" cost will
have to be borne by the developer whether they use WeakMaps or private
names or closures or whatever. Why complicate the object model, and in the
process invalidate the current maxim that all properties are reflective,
when the weight will still fall on the developer anyway?
Just an argument to consider...
Kevin
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
