Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.

Please Don't Do That. #331

Open
luciedefraiteur opened this issue Jun 5, 2021 · 8 comments
Open

Please Don't Do That. #331

luciedefraiteur opened this issue Jun 5, 2021 · 8 comments

Comments

@luciedefraiteur
Copy link

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
Copy link
Member

ljharb commented Jun 5, 2021

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

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

@gr1m1um
Copy link

gr1m1um commented Jul 28, 2021

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
Copy link
Member

ljharb commented Jul 28, 2021

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
Copy link

gr1m1um commented Jul 28, 2021

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
Copy link

gr1m1um commented Jul 28, 2021

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
Copy link
Member

ljharb commented Sep 14, 2021

@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
Copy link

trusktr commented Dec 25, 2021

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
Copy link

rdking commented Jan 8, 2022

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants