71–80 of 140 posts
"If I buy you a house and put the title in your name, but I mark some of the doors 'Employees Only', then you're not allowed to open those doors, even though it's your house. Because it's really my house, even though I gave it to you to live in." Love it!
This actually reminded me of Apple...
First note: I have never dealt with the internal workings of the Java VM, so this is just speculation. I also haven't tested any of this, but its still fun to speculate. In java private variables and functions are not accessible from outside the class. This means that the compiler would be able to make some assumptions about the nature of these members in the effect of optimization. When calling a public function of…
Earlier quoted context omitted.
Most dynamic languages use convention, which seems to work pretty well in practice. My take is that if other developers are accessing the encapsulated parts of your library, then your API or your documentation is broken - possibly both - and you should, like, fix that. Not use language features to lock them out.
One of the things that I have used access controls for is to simplify the exposed surface that collaborators work with. This isn't a condescending "I don't trust you" intention. It's more along the lines of "of all the types and methods here, you only need to know about this small subset". It's customer service, I tell ya! And if the API isn't sufficient by not exposing enough, that's fine. It's always easier to expo…
I have never been bitten by over-promiscuous code entries in Python. The times I've gone beyond the published API, I knew I was doing it so I knew I had to keep track of it. And I've gone deep here (replacing Django's database handling in their unit testing framework).
On the other hand, I can't count how many times I've been stuck in Java figuring out how to get around somebody's final class or private method that I really needed to tweak just a little bit or, worse, I needed access to a field I can see in my debugger. Needing to reflect through to get at it is STUPID.
Earlier quoted context omitted.
A big part of OO languages is encapsulation. Private fields encapsulate state and private methods encapsulate implementation details. The intention there is to make the code more robust to restrict the way collaborating classes can interact with it. Example, if you have a type representing a game score, you may want to implement a public Increment() method instead of letting other types access the score value directl…
Thanks for the response, but can you not see the source code of these private methods? And wouldn't that allow you to re-write them yourself to behave however you want?
In Drupal, for example, there is a saying: "every time you hack core (or a module you didn't write) god kills a kitten." In the spirit of open source, we probably borrowed that saying from some earlier project, because it is generally true.
The standard Java String library is the same for everyone. [1] If you download Random Java Library X, and X works with the String library, you can probably be assured that X has been tested with the standard String library. As soon as you change one line of the library this is no longer the case. You must now face the possibility that your "minor" change will lead to side effects when combined with other things, and the responsibility for finding those side effects is now entirely yours.
Plus, the sheer mechanical tedium of preserving your patch, making sure to apply it to every new version of the library as it comes out, relearning how the patch works every few months, porting the patch when it fails to apply cleanly to a new version, figuring out how to distribute your personalized package to others because they can no longer simply `apt-get` your package from the canonical repository, dealing with the fact that the standard docs and the published books might not cover your variation...
Tools like Github have made all this stuff much easier, but it's still a bad idea to tinker with others' libraries without a good reason.
The more typical advantage of open source is that you can read exactly what your library is doing, which makes it easier to figure out how to work around it without actually editing it.
---
[1] Until it isn't. But at that point it will generally get a different version number, and an official release notice, and it will have a community that is aware of the change and will promptly coordinate to find and fix any new incompatibilities with other libraries.
Earlier quoted context omitted.
Most dynamic languages use convention, which seems to work pretty well in practice. My take is that if other developers are accessing the encapsulated parts of your library, then your API or your documentation is broken - possibly both - and you should, like, fix that. Not use language features to lock them out.
One of the things that I have used access controls for is to simplify the exposed surface that collaborators work with. This isn't a condescending "I don't trust you" intention. It's more along the lines of "of all the types and methods here, you only need to know about this small subset". It's customer service, I tell ya! And if the API isn't sufficient by not exposing enough, that's fine. It's always easier to expo…
...if you're using Java, since (AFAIK) you can't switch between public fields and getters/setters. Python, however, has properties: http://www.python.org/download/releases/2.2.3/descrintro/#pr... . Point 4 of http://dirtsimple.org/2004/12/python-is-not-java.html covers why they're a good idea, though you can probably figure it out from their description.
First note: I have never dealt with the internal workings of the Java VM, so this is just speculation. I also haven't tested any of this, but its still fun to speculate. In java private variables and functions are not accessible from outside the class. This means that the compiler would be able to make some assumptions about the nature of these members in the effect of optimization. When calling a public function of…
Not quite - using reflection you can dig into private fields and do your worst to them, you just need to tag each private member's Field object with with field.setAccessible(true) before accessing it reflectively.
The only hitch is that you might get a SecurityException, but you can avoid that if you're running your code on your own JVM (by default, it should work just fine, it's if you're deploying applets or something like that where you might get the exception due to the different sandboxing rules).
"If I buy you a house and put the title in your name, but I mark some of the doors 'Employees Only', then you're not allowed to open those doors, even though it's your house. Because it's really my house, even though I gave it to you to live in." Love it!
This actually reminded me of Apple...
Earlier quoted context omitted.
One of the things that I have used access controls for is to simplify the exposed surface that collaborators work with. This isn't a condescending "I don't trust you" intention. It's more along the lines of "of all the types and methods here, you only need to know about this small subset". It's customer service, I tell ya! And if the API isn't sufficient by not exposing enough, that's fine. It's always easier to expo…
> It's always easier to expose something later than to make it private later. ...if you're using Java, since (AFAIK) you can't switch between public fields and getters/setters. Python, however, has properties: http://www.python.org/download/releases/2.2.3/descrintro/#pr... . Point 4 of http://dirtsimple.org/2004/12/python-is-not-java.html covers why they're a good idea, though you can probably figure it out from thei…
Ahhh... That was the sigh of vindication after reading this post and confirming my opinion of Steve Yegge.