All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

If you don't want instances of it, then it's not a class. In which case it's possibly (probably?) a role.

So if you've got Foo and Bar and you're not sure if if you want "Bar does Foo" or "Bar isa Foo", then ask yourself if you want Foo->new(...) to work. If you do, then Foo is clearly a class and you want "Bar isa Foo". Otherwise Foo should be a role and you have "Bar does Foo".

If you do want Foo->new(...) to work, I suppose you can get around having an isa rela

Jonathan and Stevan's advice to think "is a dog an animal, does it walk?" is commonly sensible and easy to follow, but when I code, I don't always think that way. It's easier for me to look ahead and say "am I going to create an instance of this thing? Do I want to be able to?". It helped me refactor some things to roles and I haven't looked back on those. Of course, some people naturally think of the verb.

To be fair, advice on what to do is great, but advice on why to do it is more valuable. Stevan's input was great because he was offering concrete reasons. If those reasons are pertinent to your project, than they're worth taking into account. Otherwise, I'm still unsure that holding on to inheritance is particularly worthwhile. Most of the arguments in favor of it ultimately seem to revolve around syntactic issues (as does the role debate that I've had with chromatic and others).

That's a good point (that why is more valuable than what) but to me it was too general. Actually, a lot of why is too general to me. I don't have the programming depth perception some other really good programmers might have (Stevan, yourself, I could keep naming:) and so a rule of thumb can be useful for me to judge this situation on my own. I wouldn't say it never failed me but I'll say it's been relatively good to me.

I think you need both parts. The How without the Why is, as you say, mechanical and and shallow, and prone to dogma; on the other hand, the Why without the How is too unconstrained and prone to lose touch with reality. I think Whys are not very useful in a vacuum; they must serve as justification for particular Hows in order to be worthwhile, much like Hows without a justifying Why are rarely useful (though not never – sometimes there is a meta-Why, namely, consensus).