Child classes shouldn't rely on private implementation details of their superclass.
Some OO languages have the concept of "protected" parts of their API somewhere between public and private — methods/attributes which subclasses may use, but are otherwise not part of the public API. In Perl, this can only really be accomplished by convention.
http://blogs.perl.org/users/toby_inkster/2014/07/method-privacy-in-perl.html
| [reply] |
Child classes shouldn't rely on private implementation details of their superclass.
Fine tobyink, clear and acceptable. Albeit (I am talking in general and not for some module mentioned here), a hint in the pod a la "do not subclass me, I don't like to play ball this way" would have gone further than trying to obscure. My opinion, for what is worth, is that if you write OOP then play OOP. Exhibhit your private parts but with ample of warnings not to be touched and allow for some kind of subclassing for some of your public functioning so as to move the state-of-the-art a click forward.
bw, bliako | [reply] |
do not subclass me, I don't like to play ball this way
Just because it isn't a hash that doesn't mean you can't inherit from it. It's just implemented in a way that makes using the more traditional way of implementing objects not work. "OOP" has little to do with hashes IMO.
Subclassing of Furl is still easy. You can easily write a subclass My::Furl that overrides methods on it. What is hard is attaching additional information to the object. You've been shown various ways on how to associate information with the objects.
| [reply] |
I don't think any class should indicate that they shouldn't be subclassed. It should always be possible to subclass classes. (Java's final keyword allows you to create classes like this, and it's dumb.)
Subclasses should only use the documented API of their parent class, but it should always be possible to subclass any class, and authors of classes should try to be as kind as possible to subclassers.
| [reply]
[d/l] |