3 ms·

It seems that the post argues that enforced privacy is too theoretical, in practice, advice is better than enforcement. I'd argue that the post is too theoreti

It seems that the post argues that enforced privacy is too theoretical, in practice, advice is better than enforcement. I'd argue that the post is too theoretical, in practice, enforced privacy works much better. People will do stuff against your advice. That's OK, you say - they'll get in trouble eventually, but it was their decision. However, it affects you, the library (app, etc.) developer, as your clients might turn out to be more powerful than you. Think of Linus' rant on not breaking userspace. He's right I believe. In general, you are not allowed to break client code, even the client did something he was discouraged to do. Interfaces are contracts. The ultimate documentation is the code, not the comment. You are saying that in the following case, // do not access; public int getSize(); comment has precedence over the visibility modifier. Well, no.

nathan_long 13y ago
Advisory privacy is not usually a matter of comments. In Ruby, for example `some_object.private_method` won't work, but `some_object.send('private_method')` will. The object's creator has made a machine. There are external controls and parts you need a screwdriver to get to. If you're using your screwdriver, you know it and should be OK with some risk. But the box isn't welded shut.
esailija 13y ago
In practice enforced privacy is rarely used in languages other than Javascript. In Java, C#, Ruby, Python, PHP advisory privacy is the default. You would enforce privacy when you need to run untrusted code in same process (like the Servlets model), which is not the case in any Javascript application. Enforced privacy in Javascript is also very inflexible, disabling many ways of extensiond and reuse and encouraging god objects because you cannot fine-tune the access - other internal "classes" are just as unpriviledged as some random application code. So in my eyes there are plenty of downsides for no visible upside - in all other languages the developers seem to play well and not write code to access privates. Maybe that's due to incompetence though.

nathan_long 13y ago

Advisory privacy is not usually a matter of comments. In Ruby, for example `some_object.private_method` won't work, but `some_object.send('private_method')` will. The object's creator has made a machine. There are external controls and parts you need a screwdriver to get to. If you're using your screwdriver, you know it and should be OK with some risk. But the box isn't welded shut.

esailija 13y ago

In practice enforced privacy is rarely used in languages other than Javascript. In Java, C#, Ruby, Python, PHP advisory privacy is the default. You would enforce privacy when you need to run untrusted code in same process (like the Servlets model), which is not the case in any Javascript application. Enforced privacy in Javascript is also very inflexible, disabling many ways of extensiond and reuse and encouraging god objects because you cannot fine-tune the access - other internal "classes" are just as unpriviledged as some random application code. So in my eyes there are plenty of downsides for no visible upside - in all other languages the developers seem to play well and not write code to access privates. Maybe that's due to incompetence though.