<p dir="ltr">I hadn't read the proposal properly, but the thrust of my point is the same, read remove/add `#` instead of "replace with this"</p>
<br><div class="gmail_quote"><div dir="ltr">On Fri, 12 Jan 2018, 2:47 am Naveen Chawla, <<a href="mailto:naveen.chwl@gmail.com">naveen.chwl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Massive drawback of the # semantic: making a private variable public (a common transition when the usage of a class evolves) requires a lot more refactoring, since you have to remove every # for the variable across the class and replace it with `this`. Failing to do so in just 1 instance creates a bug. The same drawback applies for privatizing a public variable, in reverse.</p>
<p dir="ltr">Besides which as an instance variable I want to learn `this` as the access prefix. I don't want to have to learn 2 different access prefixes, one for public and one for private. Access control in code only has one real material advantage: simplifying the public interface of a class by hiding factors that have no use from outside it. This is not big enough of an advantage to introduce a new access prefix, which can lead to a plethora of bugs due to confusion and/or publicization/privatization transitions during the evolution of one's system.</p>
<br><div class="gmail_quote"><div dir="ltr">On Fri, 12 Jan 2018, 1:22 am Isiah Meadows, <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Inline<br>
<br>
-----<br>
<br>
Isiah Meadows<br>
<a href="mailto:me@isiahmeadows.com" target="_blank">me@isiahmeadows.com</a><br>
<br>
Looking for web consulting? Or a new website?<br>
Send me an email and we can get started.<br>
<a href="http://www.isiahmeadows.com" rel="noreferrer" target="_blank">www.isiahmeadows.com</a><br>
<br>
On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews<br>
<<a href="mailto:warcraftthreeft@sbcglobal.net" target="_blank">warcraftthreeft@sbcglobal.net</a>> wrote:<br>
><br>
> That is a very useful document. I guess I haven't opened the proposal in a while.<br>
><br>
><br>
> He puts a lot of stress on preserving encapsulation where as I was planning on relying on a type system to optionally provide that feature. That is given a dynamically typed variable accessing privates would probably be allowed. (Statically typed variables would detect and not allow that kind of like a more strict usage).<br>
<br>
The issue with leveraging static typing is that JS has never been a<br>
statically typed language. Also, private fields are generally<br>
something you shouldn't need static types to detect - even without the<br>
sigil, it *is* in fact possible to require something like `private<br>
foo` as a declaration and alter property lookup within classes to<br>
check for local private names (for class instances) before public<br>
ones. (Decided to create a GH issue out of this:<br>
<a href="https://github.com/tc39/proposal-class-fields/issues/69" rel="noreferrer" target="_blank">https://github.com/tc39/proposal-class-fields/issues/69</a>)<br>
<br>
> I think the inheritance and using private names as keys are decent arguments. That said I'm personally not against allowing inherited classes access to their base class private members though. That is private acting like protected in C++ I think is fine for ECMAScript. Am I alone in being fine with that behavior? I'm kind of leaning toward: <a href="https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883" rel="noreferrer" target="_blank">https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883</a> that syntax for a true private class scope variable.<br>
<br>
Note: not even Java allows subclasses to access superclasses' private fields.<br>
<br>
><br>
> The key name conflict seems niche outside of key based data structures. I wrote an ORM system before and just used a key called "internal" to hold data in the past to get around a similar conflict. The # sounds like a similar workaround when required but allows everything to not be hidden in a nested object which is nice.<br>
><br>
> Are "protected" class fields a thing in this discussion at all? Or is the idea to use or implement a friend system later somehow?<br>
<br>
See <a href="https://github.com/tc39/proposal-decorators/issues/25" rel="noreferrer" target="_blank">https://github.com/tc39/proposal-decorators/issues/25</a>.<br>
<br>
><br>
><br>
> With how I use Javascript currently, and the direction I want ECMAScript to head - toward types - I don't particularly like the proposal or necessarily support its goals toward creating an ideal encapsulation. (Also I really dislike the syntax).<br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div></blockquote></div>