Concern over the hype for private properties and frozen objects

[th317erd]

I have some major concerns with the drive for Javascript to have private properties and members, and to continue down the path of "freezing" things. I feel that the ability to mutate and modify on the fly is one of the biggest reasons communities love languages like Javascript and Ruby. The argument I always see about this is some flavor of "If I am a library author, and don't want things to break...". I feel this is a terrible argument, that implies and expects that every developer is stupid and irresponsible. One of the first things I always do in almost any program I write in Javascript is set freeze and seal to NOOP Object.freeze = () =>{}; Object.seal = () => {} because I WANT to be able to modify how libraries behave. I fully understand as a responsible developer that I might be breaking things, and that I might be introducing bugs into my own code, and that should a library update come along I may need to spend a few hours adjusting things. Why can this not be my decision? Why is it for the author to decide I can not code the way I want to? This is one of the great powers of languages like Javascript and Ruby: The ability through brute force, reflection, overrides, or additions, to get the job done, instead of creating my own library from scratch, re-inventing the wheel, and adding to the already ~1m libraries on NPM.

I have always disliked the use of private and protected methods in any language (C++, Java, etc...) because of this very thing. In all my libraries I even go out of the way to make sure every aspect internally can be expanded upon, overridden, or adjusted. I can not tell you how many times in these languages I have ran into a bug, or need a simple feature, that if I could have just done an override on a private method, did my thing, and called the super method the problem would have been solved. I feel "private" methods especially scream "YOU ARE STUPID" and "YOU ARE IRRESPONSIBLE" to every developer on the planet. No... that should not be your concern as a library author. Let me do what I want to do with your library, and if I break it that is my problem.

I get it: "Yeah, but when that uneducated developer breaks my library and then blows up forms, threads, and issues with complaint after complaint about "bugs" that they caused, we will just waste hours and hours of people's time on issues that the ignorant developer themselves caused". This is two things: 1) An opportunity to educate and make better developers the world around, and 2) Why not just do some "social development" and come up with some quick ways around the social aspect that will arise from these issues? Such as common links (i.e. wikipedia) on "Dummies guide on How to fix the things you broke", etc...

TL;DR I feel (IMHO):

1. Black boxes are bad, and the burning need for them needs to stop
2. I should be able to modify whatever I want, whenever I want. The problems that arise from this can be handled with education, community reviews, and social engineering. And really should not be the concern of language specifications
3. This happens no where else in the world except in software. If I buy anything at all, and I modify it, it is immediately understood the warranty is void, all guarantees go out the window, and I am responsible for my modification. Why should software be any different?
4. I don't really understand people's urge for protecting, privatizing, black boxing, etc... so if nothing else maybe this issue could be used to educate me on this burning need so many people seem to have

Open to discussion/education here!

[ljharb]

Thanks for your thoughts!

I’m not sure this repo is the best place to have this discussion; have you tried one of the resources here?

[th317erd]

Ah thank you! I was looking for a more "forum" type place to post this, but missed that. I also thought it is a potential "issue" with the current spec/proposals, so maybe this wasn't the worst place for it to live... I can move it if you want

[ljharb]

That’s be great. Private fields aren’t even in this spec yet :-)

[bakkot]

Issues with current proposals are discussed on their issue trackers, in this case here (previously here). In this case there's an FAQ question discussing this briefly, as a fair bit of existing discussion of this topic, for example here.

[th317erd]

Thank you for the useful resources and reads @bakkot. I see a lot of argument (again from library authors) pointing out issues with Node itself and libraries like JUnit that have come to a "halt" because users of the library started messing with internals. My response to such a situation is: march forward. If the users of the library have been warned that something is internal, either through convention or language spec, and they are still messing with it, they need to be responsible and know that "warranty is void". As a library author I wouldn't care about breaking other libraries or software if they were messing with my internal state and I changed that internal state as an author... again, it is THEIR responsibility when they mess with the internal state, not mine as an author. If you make someone a great cup of java, and they add turpentine to it, and then complain that it tastes nasty... that isn't your problem.

FYI: I have moved this to the mailing list. I appreciate you referencing it elsewhere though, and I appreciate you sharing these other resources.