<div dir="ltr">The `#foo` shorthand part of the proposal was removed: <a href="https://github.com/tc39/proposal-class-fields/issues/21" target="_blank">https://github.com/<wbr>tc39/proposal-class-fields/<wbr>issues/21</a><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 11, 2018 at 2:26 PM, Isiah Meadows <span dir="ltr"><<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The proposal does a very poor job of explaining this, but `#foo` is a<br>
shorthand for `this.#foo`, much like `{foo}` is a shorthand for `{foo:<br>
foo}`. That kind of thing has precedent in other languages:<br>
CoffeeScript uses `@foo` as a shorthand for `this.foo` (although it's<br>
not private), and Ruby uses `@foo` as a shorthand for `self.foo`<br>
(which is private by default). Most traditional strongly typed OO<br>
languages just let you omit `this` and just reference the property as<br>
if it were a variable in scope, without the sigil, and Ruby does as<br>
well for methods.<br>
<br>
It saves 5 characters in the most common case, accessing private<br>
properties of the current instance.<br>
<span class="gmail-m_6207046171917575133im gmail-m_6207046171917575133HOEnZb">-----<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>
<br>
</span><div class="gmail-m_6207046171917575133HOEnZb"><div class="gmail-m_6207046171917575133h5">On Thu, Jan 11, 2018 at 4:26 PM, Naveen Chawla <<a href="mailto:naveen.chwl@gmail.com" target="_blank">naveen.chwl@gmail.com</a>> wrote:<br>
> I hadn't read the proposal properly, but the thrust of my point is the same,<br>
> read remove/add `#` instead of "replace with this"<br>
><br>
><br>
> On Fri, 12 Jan 2018, 2:47 am Naveen Chawla, <<a href="mailto:naveen.chwl@gmail.com" target="_blank">naveen.chwl@gmail.com</a>> wrote:<br>
>><br>
>> Massive drawback of the # semantic: making a private variable public (a<br>
>> common transition when the usage of a class evolves) requires a lot more<br>
>> refactoring, since you have to remove every # for the variable across the<br>
>> class and replace it with `this`. Failing to do so in just 1 instance<br>
>> creates a bug. The same drawback applies for privatizing a public variable,<br>
>> in reverse.<br>
>><br>
>> Besides which as an instance variable I want to learn `this` as the access<br>
>> prefix. I don't want to have to learn 2 different access prefixes, one for<br>
>> public and one for private. Access control in code only has one real<br>
>> material advantage: simplifying the public interface of a class by hiding<br>
>> factors that have no use from outside it. This is not big enough of an<br>
>> advantage to introduce a new access prefix, which can lead to a plethora of<br>
>> bugs due to confusion and/or publicization/privatization transitions during<br>
>> the evolution of one's system.<br>
>><br>
>><br>
>> On Fri, 12 Jan 2018, 1:22 am Isiah Meadows, <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> 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><wbr>> wrote:<br>
>>> ><br>
>>> > That is a very useful document. I guess I haven't opened the proposal<br>
>>> > in a while.<br>
>>> ><br>
>>> ><br>
>>> > He puts a lot of stress on preserving encapsulation where as I was<br>
>>> > planning on relying on a type system to optionally provide that feature.<br>
>>> > That is given a dynamically typed variable accessing privates would probably<br>
>>> > be allowed. (Statically typed variables would detect and not allow that kind<br>
>>> > 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/propos<wbr>al-class-fields/issues/69</a>)<br>
>>><br>
>>> > I think the inheritance and using private names as keys are decent<br>
>>> > arguments. That said I'm personally not against allowing inherited classes<br>
>>> > access to their base class private members though. That is private acting<br>
>>> > like protected in C++ I think is fine for ECMAScript. Am I alone in being<br>
>>> > fine with that behavior? I'm kind of leaning toward:<br>
>>> > <a href="https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883" rel="noreferrer" target="_blank">https://github.com/tc39/propos<wbr>al-private-fields/issues/14#<wbr>issuecomment-216348883</a><br>
>>> > that syntax for a true private class scope variable.<br>
>>><br>
>>> Note: not even Java allows subclasses to access superclasses' private<br>
>>> fields.<br>
>>><br>
>>> ><br>
>>> > The key name conflict seems niche outside of key based data structures.<br>
>>> > I wrote an ORM system before and just used a key called "internal" to hold<br>
>>> > data in the past to get around a similar conflict. The # sounds like a<br>
>>> > similar workaround when required but allows everything to not be hidden in a<br>
>>> > nested object which is nice.<br>
>>> ><br>
>>> > Are "protected" class fields a thing in this discussion at all? Or is<br>
>>> > 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/propos<wbr>al-decorators/issues/25</a>.<br>
>>><br>
>>> ><br>
>>> ><br>
>>> > With how I use Javascript currently, and the direction I want<br>
>>> > ECMAScript to head - toward types - I don't particularly like the proposal<br>
>>> > or necessarily support its goals toward creating an ideal encapsulation.<br>
>>> > (Also I really dislike the syntax).<br>
>>> > ______________________________<wbr>_________________<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/listi<wbr>nfo/es-discuss</a><br>
>>> ______________________________<wbr>_________________<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/listi<wbr>nfo/es-discuss</a><br>
______________________________<wbr>_________________<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/listi<wbr>nfo/es-discuss</a><br>
</div></div></blockquote></div><br></div></div>