search

tc39 / proposal-class-fields

Orthogonally-informed combination of public and private fields proposals
https://arai-a.github.io/ecma262-compare/?pr=1668
1.72k stars 113 forks source link

Please Don't Do That. #331

Open luciedefraiteur opened 3 years ago

luciedefraiteur commented 3 years ago

I really often need to access private fields in librairies i use in order to fix small issues, as a workaround, cause the library is badly done, really really often, or just to debug quickly something, would be really boring and against whats good in javascript, to force people to respect private members.

Please do not add this feature.

ljharb commented 3 years ago

It’s already stage 4. It’s added.

If you want to change private fields, change the code.

gr1m1um commented 3 years ago

what's the motivation for this change? whoever though of this never used js that much, one thing that makes js nice is the ability to access and change objects, this seems a poor choice, with some luck linters will discourage it as bad practice, damage is done though

ljharb commented 3 years ago

The most important feature in JS is to use lexical scoping to prevent access to things. The ability to access things by default is not something that makes the language nice.

gr1m1um commented 3 years ago

makes some sense but in practice its often handy to change and check things, being a plain language and malleable I think its a big plus of js, I can't find the motivation for this proposal written down or think its reasonable

gr1m1um commented 3 years ago

okay there is some explanation on the docs, makes sense to separate public from private api also many times ran into this or wish private fields could be more explicit, still considering the downsides don't think this is an improvement

ljharb commented 3 years ago

@jbreckmckye no, it does not make it moot at all. The concern is about changing things at runtime. It’s never been and never will be possible to prevent changing the code at compile time.

trusktr commented 2 years ago

The fact that a library author can add private fields to a class used as implementation detail and unknowingly break all consumers is quite a big downfall of the current private fields.

rdking commented 2 years ago

Assuming a library author is willing to give up any semblance of the ergonomics that TC39 thought was so very important, it's possible to actually use private fields in a library in a way that is completely non-disruptive to downstream users. However, the fact that this kind of non-ergonomic coding has to be used just to fully ensure that my use of private fields doesn't disrupt how others want to use my code only highlights how many unfortunate conflicts of interest went into this proposal.

Oh well. It's not like they're going to fix it at this point. The damage is already done. No real use in complaining about it. We can either work around it, or opt to not use it. That's all we've got.