Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Here's what I've been using:

    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 relationship by making a MyRole and say that "Foo does MyRole" and "Bar does MyRole". But then take Stevan's point about "Is this a true is-a relationship?" and wonder if you're just being a bit too role-happy.
    • That's what I do as well, it just makes the most sense to me.

      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.

      It's nice to see how there's good advice

      • 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.

          As for a situation I might want MI? How about...

          # this is probably a stupid example,

        • 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).