Hacker News Reader

Comment by i386 | Hacker News Reader

Isn’t the point that private fields remain private implementation details of the class in just about every language that has them?

As a library author, if I declare something as private, it means you the consumer, may damage internal state in some way by directly mutating those fields.

If they do need to be read or mutated, that’s a good case for adding to the public API, not complaining that reflection tricks can’t get at something you shouldn’t have access to. Not to mention how incredibly fragile your consumer is going to be when upgrading… I feel like the JS folks are learning the same lessons the hard way that the Java folks did 25 years ago.

View on HN

The article seems quite practical.

She wants her users to be able to use Proxies over her classes. Private members make a class ineligible for proxying. So she'd rather use private-by-convention.

"So she'd rather use private-by-convention."

This effectively and automatically devolves to "public-by-contract". Seen it happen so many times that you can't convince me otherwise.

There is actually a stage 2 proposal "Function Implementation Hiding" that is being pushed through despite the many very legitimate and thoroughly described concerns that people have been voicing on GitHub and everywhere else this topic is brought up.

https://github.com/tc39/proposal-function-implementation-hid...

What are the concerns, actually? I have seen this proposal before, and I don’t recall any significant concerns.

A quick glance over the GitHub issue titles should give you a general idea.

Whilst I don't personally share all of the concerns posted there and even believe some of them are a little bit silly, I have to say that I do not at all like the way most of the discussions are abruptly cut short or simply left unanswered, and how difficult questions or ideas that aren't entirely in line with the original proposal are immediately declared nonsensical/invalid or shot down without any further exploration at all.

The above is a common theme in that repo and not difficult to find. I've never seen that kind of behaviour in any other proposal at that stage. Very sad to see.

https://github.com/tc39/proposal-function-implementation-hid...

"I bet ljharb is involved with this one too"

_checks first issue_ yep.

Isn’t most Javascript rendered useless by the time it is ready to be upgraded because all of its dependencies have moved on to not so greener pastures?

On a serious note. Keeping up with changes in the Javascript community seems like a full time job. I don’t know how they get any work done.

This joke was already getting old 6 years ago.

The major frameworks of today were already well established then, and the last really big update to the language in 2015 had already been in fairly wide spread use via transpilers (traceur and later 6to5, which became babel).

Honestly, in the last 13 years, many mainstream languages have gone through similar churn. JavaScript has gone through more than most, to be sure, but nobody complains about Rust or C# nearly so much.

JS is dependencies all the way down. Upgrading things can be a nightmare

And yet, I find myself struggling way more with Objective-C/Swift and Java/Kotlin deps than I do with JS ones. Dependency upgrades can be problematic, sure, but JS is no worse than any other language. I never had to change compiler flags or mutate internals of a library in npm the way I need to do with cocoapods.

> Honestly, in the last 13 years, many mainstream languages have gone through similar churn. JavaScript has gone through more than most, to be sure, but nobody complains about Rust or C# nearly so much.

Rust appeared 7 years ago. Rust did not went through any churn. Arguably, the first iteration hasn't even ended yet.

Of course it has, that’s what editions are. If you don’t consider editions different then the first version of JavaScript hasn’t ended either.

> Of course it has, that’s what editions are.

They really aren't. Editions are just a mechanism to allow Rust developers to push backwards-incompatible changes as opt-in features. I repeat, Rust hasn't even went through its first iteration, and it shows a fundamental lack of understanding and insight to argue otherwise.

I don't think it was a joke, and the problem is real. Last year I had to spend significant amount of time updating a basic frontend that was "only" three years old. "npm install" told me I had over a hundred security problems (most weren't really applicable or a big deal, but still), but updating things was hard as almost everything had incompatible changes; some had several major version bumps. Since I didn't write the original application and wasn't familiar with all the libraries used it felt like joining Game of Thrones in the middle of season 4 and figuring out what was going on. All in all, I spent about a week of full-time work.

The backend was written in Go; everything could be updated to the latest version without any incompatibilities at all.

People having been complaining about incompatibilities in Rust too, but Rust is a much newer language, and I think things have settled by now as well. I don't know much about C#.

Sure, and in another three years you'll be saying the same thing about go because the introduction of genetics has changed everything. Java went through the same thing with the transition of java 9, introduction of lambdas, etc. Python went through 2 to 3 in the same time period. C++23 is in the works, and many parts of the ecosystem are just now getting support for 11.

I'm not saying the problem doesn't exist, or that's certain parts of the ecosystem haven't experienced more churn than others. I am saying that "js churn" has been a meme joke for a long time, and has been old for almost as long.

> in another three years you'll be saying the same thing about go because the introduction of genetics has changed everything

I'm not so sure about that; things haven't really changed that much. A language gaining new features doesn't typically break everything, even when libraries start adopting them.

But even if it does: sure, languages can have their "everything changed" watershed moments, but no such watershed happened in JS in the last few years, yet updating things is still a lot of effort, and a bit of a pain.

It actually has nothing to do with the language; it's just the mindset. For whatever reason compatibility is just not high on the list of priorities in the JS ecosystem. I maintain Go packages that have been compatible for over 10 years; I make special effort to ensure they remain compatible, and even if a compatibility break is required I try to minimize it. There is nothing in JS or npm preventing the same kind of mindset.

Either way, it's not a "meme joke" and it's certainly not "old" as the problems still exist today. If you (or someone else) would say "I think the advantages of moving faster are more important than remaining compatible": okay, fair enough; I can see that's a reasonable point of view, even though I personally don't agree with it. What I always find off-putting is the casual dismissal of the problems. The Python 3 transition could have been handled better and dependency management remains a bit of a mess in Python: I don't see many Python developers deny these are (or were) real problems.

Eh, most of the time, if you use private, what you really wanted was protected.

Private causes extensibility issues (no access to private fields in child classes). Not sure if the article addressed this or not because it's currently hugged to death.

It does.

No, most of the time, if I use private, what I really wanted is private. And it does exactly what I want. So speak for yourself.

Protected plus subclassing is just poor man's dependency injection; entirely dispensable.

https://archive.ph/ffvTF

Reply on news.ycombinator.com