New private names proposal

[Brendan Eich]

On Dec 22, 2010, at 6:39 PM, David-Sarah Hopwood wrote:

> Inspectors can bypass encapsulation regardless of the language spec.

The Inspector is written in ES5. How does it bypass soft field strong encapsulation?

> As for "the ability to manipulate all properties of objects at a meta
> level using reflection", strictly speaking that is still possible in the
> soft fields proposal because soft fields are not properties. This is not
> mere semantics; these fields are associated with the object, but it is
> quite intentional that the object model views them as being stored on a
> side table.

The side table is in a closure environment only, not available to the inspector, which uses getOwnPropertyNames:

function MyConstructor(x, ...) {
   const mySoftField = SoftField();
   mySoftField.set(this, x);
   ...  // closures defined that use mySoftField
}


> Note that other methods of associating private state with an
> object, such as closing over variables, do not allow that state to be
> accessed by reflection on the object either.

That's right, and that is exactly Allen's point in writing the rationale for weak encapsulation that he wrote, and my point in using the example ReliableFred relies upon: an inspector hosted in the browser written in ES5.

You wrote too long a reply again, with lots of extra words claiming to rebut me, but you got this fundamental part of the example completely wrong, and inverted the rationale for weak encapsulation.

We do not want to require a deoptimizing native code hosted debugger or inspector to peek in closures. Even if you have one, finding the soft field requires the user to know where to look. With private names, there's no mystery: you look on the object itself, using getOwnPropertyNames.

Please reply in <500 words.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101222/4acdf73c/attachment.html>