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
