Re^6: Inheritance problem: Not a HASH ref

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

Comment on Re^6: Inheritance problem: Not a HASH ref

Replies are listed 'Best First'.
Re^7: Inheritance problem: Not a HASH ref by Corion (Patriarch) on Feb 26, 2019 at 22:02 UTC
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]
Re^8: Inheritance problem: Not a HASH ref by bliako (Abbot) on Feb 26, 2019 at 22:24 UTC
Yes, I got the various ways of attaching info to such objects (confession: `$$self->{'xyz'} = 42` is what I would seek first - and I should have realised myself) thanks to the respondents to this question. It's just I sense that maybe is not a "good" thing to do, given that the author did not make it explicit/easy to subclass for users. Btw, from Furl's source I see in `new()` `... return bless \(Furl::HTTP->new(header_format => Furl::HTTP::HEADERS_AS +_HASHREF(), @_)), $class;` [download] And now I wonder whether this "special" blessing which has been tormenting me was just because of not wanting to explicitly subclass.	[reply] [d/l] [select]
Re^7: Inheritance problem: Not a HASH ref by tobyink (Canon) on Feb 28, 2019 at 12:25 UTC
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. toby döt ink	[reply] [d/l]