Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re^4: Inheritance, just say no! Read the traits paper!

by apotheon (Deacon)
on Aug 04, 2006 at 07:28 UTC ( #565619=note: print w/replies, xml ) Need Help??

in reply to Re^3: Inheritance, just say no! Read the traits paper.
in thread Inheritance: the root of the problem

I think you misunderstood what I was saying. I didn't mean that "inheritance v. not-inheritance" is the same as "poe-tay-toe v. poe-tah-toe". Rather, I mean that "How can we boil a (perceived) necessity for inheritance down to its essentials, in the form of underlying problems it's meant to solve?" is "poe-tay-toe", while "What are the problems we might solve with inheritance, and do we need inheritance or something else entirely to solve them in this case?" is "poe-tah-toe". In other words, I'm referring to different means of phrasing the question as being nearly equivalent (we're talking about the same thing in different languages). The refactor of my question is a better approach to explicitly describing the intent of the question, but it ultimately amounts to roughly the same question, as far as I can see.

On the other hand, I can't say I'm unhappy I failed to be clearer about my "poe-tay-toe versus poe-tah-toe" statement, because it prompted to you to say a bunch of stuff that helps me think more clearly about the problem at hand. I'd never really encountered lucid explanations of the traits/roles approach before my OP here, and between you and others I've received some good indications about how to approach figuring out what it's all about. Thus, thanks.

print substr("Just another Perl hacker", 0, -2);
- apotheon
CopyWrite Chad Perrin

  • Comment on Re^4: Inheritance, just say no! Read the traits paper!

Replies are listed 'Best First'.
Re^5: Inheritance, just say no! Read the traits paper!
by tilly (Archbishop) on Aug 04, 2006 at 10:51 UTC
    Those similar questions emphasize different things, so will lead you to different answers.. And they go hand in hand with the third essential question, which is, What are the problems that inheritance causes?

    The key to understanding all three is that inheritance is an imperfect mechanism for turning an ontology into well-factored code. Debates over what kind of inheritance mechanism to use come down to debates over how rich we'll allow our realizable ontologies to become (noting that richness brings both benefits and drawbacks), how efficient we wish the implementation to be, and where we wish to place surprises for the unwary programmer. (One of the tradeoffs is that the richer we allow the ontology to become, the more surprises we wind up with.)

    It is, to say the least, highly unclear what the optimal tradeoff is. In fact it is apparent to me that the optimal tradeoff is different in different situations, and is again different for different programmers. Therefore beyond vague generalities (like the ones I give above), a real discussion of this problem needs to be informed by concrete examples. Certainly trying to answer it in perfect abstract generality is bound to fail.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://565619]
and the monastery is silent...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (3)
As of 2017-04-29 19:00 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (534 votes). Check out past polls.