<div dir="ltr">I can make it work work under my proposal-object-members by making '#' a postfix unary operator, but then it would have to be a syntax error to use it that way unless we're dealing with a destructuring operation. That just opens up too many ways to abuse it and leak the private container. So that's a no-go as well.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 6, 2018 at 10:45 AM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com">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"><div><div dir="auto">BTW, this just falls out of the grid with my private symbols suggestion....</div><a href="https://github.com/tc39/proposal-class-fields/issues/115" target="_blank">https://github.com/tc39/proposal-class-fields/issues/115</a></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 6, 2018 at 10:14 Ranando King <<a href="mailto:kingmph@gmail.com" target="_blank">kingmph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I can understand why this would be wanted. It would save some excess typing. However, doesn't it also lead to the potential foot-gun of forgetting to assign any modifications back to the original private field? Also, since private fields aren't actually own properties of the instance, how could they possibly be destructured? There's no programmatically exposed listing of the private fields. Further, under proposal-class-fields private fields are restricted to just `class` instances, so the destructuring syntax doesn't make sense for that scenario. Basically it would imply that the following is true:<div><br></div><div>```js</div><div>let bar1 = "bar", bar2;</div><div>({ #fubar: bar2}) = { #fubar: bar1 };</div><div>bar1 === bar2;</div><div>```</div><div><br></div><div>Even if proposal-class-fields allowed for private fields on objects, it wouldn't work. There's no way to reify the left side's `#fubar` as a private name of the object on the right side before processing the object on the right side. Put another way, without `obj.` in front of it, `#field` cannot be lexically resolved as a private name while parsing unless the parser, upon finding the object on the right side of the `=`, re-evaluates the left side. Since destructuring can be arbitrarily complex, this becomes a mess very nearly as complex as trying to accurately deep clone an arbitrary object.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 5, 2018 at 3:12 PM kdex <<a href="mailto:kdex@kdex.de" target="_blank">kdex@kdex.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Often times, when I use a class field a lot, I create a local binding for it, <br>
so that I don't have to prefix every appearance with `this.`:<br>
<br>
```js<br>
class Foo {<br>
        bar = 1;<br>
        method() {<br>
                const { bar } = this;<br>
                /* … */<br>
        }<br>
}<br>
```<br>
<br>
The same approach would currently be illegal syntax if `bar` is declared to be <br>
private:<br>
<br>
```js<br>
class Foo {<br>
        #bar = 1;<br>
        method() {<br>
                const { #bar } = this;<br>
                /* … */<br>
        }<br>
}<br>
```<br>
<br>
How is the destructuring assignment supposed to behave anyway? Introduce a <br>
local `bar` binding, just like above?<br>
<br>
Whatever it should do, even defining an explicit name for the binding is <br>
currently illegal:<br>
<br>
```js<br>
class Foo {<br>
        #bar = 1;<br>
        method() {<br>
                const { #bar: bar } = this;<br>
                /* … */<br>
        }<br>
}<br>
```<br>
<br>
This feels really asymmetric to public fields and has come up in the class <br>
fields proposal[1] before, though it was suggested to defer it to a separate <br>
proposal.<br>
<br>
Is someone currently working on said proposal?<br>
<br>
[1] <a href="https://github.com/tc39/proposal-class-fields/issues/4" rel="noreferrer" target="_blank">https://github.com/tc39/proposal-class-fields/issues/4</a>_______________________________________________<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>
_______________________________________________<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>
</div>
</blockquote></div>