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