>
> It all start because of a fundamental missing piece in the language that
> is the ability to add a private property to an object. Not socially private
> as per the _field convention. I mean actually private, enforced by the
> runtime.
>
I've been pondering this for a while now, and I think I've figured out
what's bothering me...
I think privately named fields are a great addition to the language:
let privateThing = new Symbol(); // Or whatever the API is...
class X {
constructor() { this[privateThing] = "something"; }
}
This is good.
However (imagining that we have Allen's private name syntax):
let privateThing = new Symbol(); // Or whatever the API is...
class X {
@privateThing() { console.log("I'm private!"); }
}
This is not, because now class X is (probably unintentionally) un-mixable,
for the reasons stated previously. As we said before, we could use a
unique name here, but the distinction between private and unique names is
very subtle and probably easy to miss.
We are conflating the privacy solution with the name-conflict solution.
Since each solution has different and subtle runtime implications, there
should be a clear and distinct way for the user to select between them.
I argue that the current proposal does not make a sufficient distinction
between private and unique names to lead the user to the correct choice.
If that is a problem, then what are the options?
1) Is method name-collision a practical problem, or just a theoretical
problem? If it's just a theoretical problem, then we don't need unique
names, and in teaching the language we can simply guide users away from
trying to create "private methods". In fact, without supporting syntax
it's unlikely that users would even bother trying to create them in the
first place.
(This would mean that the iterator hook would need to be called simply
"iterator".)
2) Provide two distinct constructors for private and unique names, and
provide supporting method syntax ONLY to unique names. This will ensure
that private names are not incorrectly used as prototype method names.
(If unique names are provided, then there will have to be some supporting
method syntax, as Allen has suggested.)
I currently lean toward option 1.
Kevin
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
