tilly, you have a tendency to toss out statements like that without explaining what you mean (that's not intended as criticism.) Are you stating that all OO languages are like this? Clearly you are referring to more than just a blessed referent. With much tighter encapsulation available with Java or C++, do you mean even these languages have the programmer automatically mucking with internals upon subclassing or is this a peculiarity of Perl (or dynamically-typed languages)?
| [reply] |
I was stating a general rule for all OO languages. There may be additional traps in Perl, but it is true in general.
When I declare a subclass, I'm saying that A isa B. Making this work generally requires that A and B cooperate to some extent. At a minimum, the author of A needs to know what methods B is likely to expect to see overridden. Missing some of them may mean that your object behaves weirdly. Sometimes you need access to class data. In many languages the subclass implementor has access to special protected functions, and needs to know when they are supposed to be called. All of this may need updating if the parent module changes. And so on.
In short, the concept of "isa" represents reasonably tight coupling between components. Some of the tightness is accidental - such as the result of the visibility of the implementation in Perl. But some is intrinsic to what OO is. If you're unwilling to accept this coupling, then you probably shouldn't be subclassing.
Remember that OO provides a series of potential compromises between reducing duplication of information and reducing coupling. It is good to not duplicate information. It is good to have loose coupling. Those goals are good because each avoids a difficult problem. Unfortunately they naturally conflict, reducing duplicate information naturally couples things together.
Among those potential compromises, inheritance is the choice that gives the best opportunity for removing duplication of information. But at a natural cost of tighter coupling.
| [reply] |
Can't speak for tilly, but it's defaintely something that effects pretty much any language, though Perl might be worse off than most. If you have a method in your subclass, you always run the risk that the parent class will define a method with the same name, but with very different functionality.
I don't remember how the method is searched for in Java, but I believe that if you call that method in the parent, then it calls the parent class's version. This isn't true in Perl without some tricks.
----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.
| [reply] |
If you have a method in your subclass, you always run the risk that the parent class will define a method with the same name, but with very different functionality.
Not so. In C++, a method must be explicitly declared as virtual if you wish to allow it to be overridden in subclasses. As a result, a if you call a superclass method and that method calls the method foo(), it will only grab the subclass foo() if the superclass had declared foo() as virtual. (At least, that's my understanding. C++ is not my strong suit.)
In Java, you can declare a method as private and subclasses cannot override that method.
I'm still not sure how subclassing messes with something's internals, though. In Perl, it's pretty much a given that this will happen since there is so little support for encapsulation. This ties in with my comments above. I don't know if tilly meant all OO languages.
| [reply] |
