Closed eddyw closed 6 years ago
Async private methods are supported in this proposal, as async #method() { }
. Private fields and methods are not forwarded through Proxies. Protected is proposed to be handled in a follow-on decorators proposal. This seems to be mostly a dup of #59, so closing this issue.
How could we allow a
private
field to be shared only when subclassing but not when it's an instance? Why notprotected
fields were not proposed? Have you thought if in the future somebody does propose them? (we are running out of characters)I know it was discussed many times why
$
was chosen (I read the FAQs). It's ugly but I get it. However, that doesn't mean there cannot be another way of declaring them. What about this?:Declaring them that way makes more sense besides it doesn't break the current proposal's idea. However, if somebody comes up with "this may be confusing..." or similar, devs do not seem confused using
static [prop]
, they know how to access a static var (new.target[propName]
). In a similar way,private [prop]
won't make it more confusing, devs will know to access withthis.#[prop]
.An example where it will look better:
What about async functions?
How will it behave with destructuring. For instance (with no Private fields):
With private fields:
~Are private fields not
enumerable
?, I mean, is it possible to get all the names of private fields from inside a class? If they are not enumerable, how does it affect applying a function decorator and changing the descriptor toenumerable: true
?~ got it :PHow does it act with
Proxy
?So far I have more questions that actually use cases since I'm not pretty sure how much does it affect everything we know about JS. Now we have
block scope
vars andfunction scope
vars. Maybe explaining how to categorizeprivate block/function scope
vars will clarify better all questions.