Skip to content

Comment on Closures for class/module privacy considered harmfulparent

Comments

There isn't true privacy by default in Java or C# so how can they get by? Are they relying on the fact that programmers won't use reflection to access private? Does the client run the program with security manager on? What if the application cannot afford to run with security manager on?

I don't disagree with anything you said, which makes me think I worded my response incorrectly. I was using the author's term "true privacy", but what I meant is traditional privacy that, when not explicitly attempting to circumvent it, will generate some negative action, such as a warning or a compilation error. My problem was the author's blanket assertion that this type of privacy is bad and should be avoided, even if it is available.

What is meant by true/enforced privacy is that the only way to access something is to modify the original source. This is not the default anywhere else, as you know, but is encouraged by some (Crockford for example) in Javascript.

Enforced/True privacy is very bad, and the badness is multiplied by the fact that in Javascript it cannot be fine-tuned so when you are making it private for random application code, you are also making it private for other internal classes.

Those warnings are not part of the language, and can be done with underscore prefixed Javascript too in your build step, a fine example of programming into one's language.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.