"Considered harmful" is the code word for passive-aggressively manipulating an opinion as truth. Whenever I see it, I would mentally say, fuck you, just state your opinion as opinion and don't try to twist it around.
Back to the blog. Contrast to the claim, closure for class/module privacy is great because it separates inner implementation from public interface. I really don't want any outside code to touch the private code. Because tomorrow I might change the inner implementation, function signature, break the function into two pieces, or proxy-call other libraries. And I want the assurance that the change won't break any calling codes.
Public function is like global variable. Anyone can access it anywhere and anytime. You don't know how, where, and when people call it. If you change its signature, you pretty much have to hunt down every call of it to retrofit. Private codes have no such issue. It's best to limit the scope of codes that are intended to be private.
Testing private code is a non-issue. Nobody outside cares about your private functions. They care about your public functions serving as the public interface. You test your public functions as your users would call them. Your public functions in turn exercise the private functions.
If you really want to test the private functions, write private tests in the same scope as the private functions to call them.
Why hide it completely? What about exposing your interface by convention like in Python? Never heard anyone suffering from inability to make methods and fields private in Python.
Edit: Why not make all variables global? Why not just use convention to label a globally scoped variable as "global" or as "local"? You can make it work as a convention. Now apply that to the whole language and to all the developers ever use it.
Well, that depends on your starting point, if you're a private state proponent then it may be a hack for you. I'm more of a control freak and I'm on a side of 'everything is public, lets code by interface', so for me private state is a bit of a hack that some languages have because some other languages have it and and some other languages have because it was introduced in languages before them. My point was that the lack of private state in Python didn't made impossible to separate inner implementation from public interface.
Why not make everything global? For obvious reasons - modularity, memory consumption, and inconvenience of lengthy variables names.
If you are a control freak and you are writing a library, you would want to control how and where people can call your code. Most languages support private function because it has found to be a good idea. Sure most of them are doing it as a hack.
It is exactly the point where our interests collide - when I'm using your library, I want to have a control over your library, because I'm using it. I don't want you library to control me an the way I use it. It's a tail wagging the dog analogy.
For example I use your library and everything goes great until I'm stuck because I need to have an information hidden in a private field, if I'm in Python I would do it and add a note, fixme, todo, whatever that this is a hack and things may break in a future, but my code would work right now. And I can fork your library later and submit changes. If this is a language with real private support the only way is to use hacks (reflection) which is the same as using the field directly like in python just with some additional PITA, or to fork your library and maintain it until you merge changes, or if you not, I have to maintain it forever.
Comments
"Considered harmful" is the code word for passive-aggressively manipulating an opinion as truth. Whenever I see it, I would mentally say, fuck you, just state your opinion as opinion and don't try to twist it around.
Back to the blog. Contrast to the claim, closure for class/module privacy is great because it separates inner implementation from public interface. I really don't want any outside code to touch the private code. Because tomorrow I might change the inner implementation, function signature, break the function into two pieces, or proxy-call other libraries. And I want the assurance that the change won't break any calling codes.
Public function is like global variable. Anyone can access it anywhere and anytime. You don't know how, where, and when people call it. If you change its signature, you pretty much have to hunt down every call of it to retrofit. Private codes have no such issue. It's best to limit the scope of codes that are intended to be private.
Testing private code is a non-issue. Nobody outside cares about your private functions. They care about your public functions serving as the public interface. You test your public functions as your users would call them. Your public functions in turn exercise the private functions.
If you really want to test the private functions, write private tests in the same scope as the private functions to call them.
Why hide it completely? What about exposing your interface by convention like in Python? Never heard anyone suffering from inability to make methods and fields private in Python.
Because it's a hack in Python.
Edit: Why not make all variables global? Why not just use convention to label a globally scoped variable as "global" or as "local"? You can make it work as a convention. Now apply that to the whole language and to all the developers ever use it.
Well, that depends on your starting point, if you're a private state proponent then it may be a hack for you. I'm more of a control freak and I'm on a side of 'everything is public, lets code by interface', so for me private state is a bit of a hack that some languages have because some other languages have it and and some other languages have because it was introduced in languages before them. My point was that the lack of private state in Python didn't made impossible to separate inner implementation from public interface.
Why not make everything global? For obvious reasons - modularity, memory consumption, and inconvenience of lengthy variables names.
If you are a control freak and you are writing a library, you would want to control how and where people can call your code. Most languages support private function because it has found to be a good idea. Sure most of them are doing it as a hack.
It is exactly the point where our interests collide - when I'm using your library, I want to have a control over your library, because I'm using it. I don't want you library to control me an the way I use it. It's a tail wagging the dog analogy.
For example I use your library and everything goes great until I'm stuck because I need to have an information hidden in a private field, if I'm in Python I would do it and add a note, fixme, todo, whatever that this is a hack and things may break in a future, but my code would work right now. And I can fork your library later and submit changes. If this is a language with real private support the only way is to use hacks (reflection) which is the same as using the field directly like in python just with some additional PITA, or to fork your library and maintain it until you merge changes, or if you not, I have to maintain it forever.
This. And if you want to extend, encapsulate.