> To discover what's written into the supposedly private x, just call SetX
on an object that's not an instance of Foo.
Actually, it's fairly trivial to avoid that issue in the engine. As long as
both objects and functions know what private data they have access to, then
all you need is a check to determine whether or not the object instance has
access to the same private data as the function. If not, throw a TypeError
et voilà, no leaks. That's part of how my POC works. The real difficulty
with not having a <PRIVATE> marker on the access comes only because JS
programmers are so very used to being able to tack a new property on to any
object they see, and readily abuse this capability to amazing effect. Given
that only the creator of an object should be able to manage its private
properties, and that these properties must always exist even if undefined
(they're considered implementation details), property access quickly
becomes a minefield as objects with private members pass through code
intent on attaching new public members, even if they're just temporary.
On Tue, Aug 7, 2018 at 4:29 PM Waldemar Horwat <walde...@google.com> wrote:
> On 08/03/2018 08:30 PM, Bob Myers wrote:
> > > `private`, `protected`, `class`, and a few other such keywords have
> all been part of ES since long be for the TC39 board got their hands on it.
> They hadn't been implemented, but they were all a very real part of ES.
> >
> > Whoa. Is that just misinformed or intentionally misleading? They have
> never been "part of ES" in any meaningful sense. It was not that they had
> not been implemented; it was that they had not even been defined. To say
> they are a "real part of ES" is a strange interpretation of the meaning of
> the word "real". The notion that we would choose features to work on based
> on some designation of certain keywords as reserved long ago, and that they
> are now "languishing", is odd. Why not focus on "implementing" enum, or
> final, or throws, or any other of the dozens of reserved words?
> >
> > Having said that, I think it is a valid general principle that as
> language designers we should be very reluctant to use magic characters.
> `**` is fine, of course, as is `=>`, or even `@` for decorators.
> Personally, I don't think the problem of access modifiers rises to the
> level of commonality and need for conciseness that would justify eating up
> another magic character. We also don't want JS to start looking like Perl
> or APL.
> >
> > Speaking as a self-appointed representative of Plain Old Programmers, I
> do feel a need for private fields, although it was probably starting to
> program more in TS that got me thinking that way. However, to me it feels
> odd to tie this directly to `class` syntax. Why can't I have a private
> field in a plain old object like `{a: 1}` (i.e., that would only be
> accessible via a method on that object? We already have properties which
> are enumerable and writable, for example, independent of the class
> mechanism. Why not have properties which are private in the same way?
> >
> > The problem,of course, is that even assuming the engines implemented the
> `private` property on descriptors, I obviously don't want to have to write
> `Object.create({}, {a: {value: 22, private: true})`. So the problem can be
> restated as trying to find some nice sugar for writing the above. You
> know, something like `{a<private>: 22}`. That's obviously a completely
> random syntax suggestion, just to show the idea. Perhaps we'd prefer to
> have the access modifiers be specifiable under program control as an object
> itself, to allow something like
> >
> > ```
> > const PRIVATE = {private: true};
> >
> > const myObject = {a(<PRIVATE>: 2; }
> > ```
> >
> > But what would the precise meaning of such as `private` descriptor
> property be? In operational terms, it could suffice to imagine (as a
> behavior, not as an implementation strategy) that objects would have a flag
> that would skip over private properties when doing property lookups. I
> think the right implementation is to have a private property look like it's
> not there at all when access is attempted from outside the object (in other
> words, is undefined), rather than some kind of `PrivatePropertyAccessError`.
> >
> > The above approach ought to be extensible to class notation:
> >
> > ```
> > class Foo (
> > bar<PRIVATE>(): { return 22; }
> > }
> > ```
> >
> > which would end up being something like
> `Object.defineProperty(Foo.prototype, "bar", {value() {return 22; },
> private: true})`.
> >
> > Or when classes get instance variables:
> >
> > ```
> > class Foo {
> > bar<PRIVATE> = 22;
> > ```
> >
> > Was anything along these lines already brought up in this discussion?
>
> Yes. There are a couple answers:
>
> - If you have the <PRIVATE> marker on both definitions and accesses of the
> property, then you get a proposal that's essentially isomorphic to the
> committee's current private proposal.
>
> - If you have the <PRIVATE> marker on definitions but not accesses of the
> property, then the proposal leaks private state like a sieve:
>
> For example:
>
> class Foo (
> x<PRIVATE>;
>
> SetX() {this.x = <some secret>;}
> }
>
> To discover what's written into the supposedly private x, just call SetX
> on an object that's not an instance of Foo.
>
> There are analogous examples for reading instead of writing.
>
> Waldemar
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
