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

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.	[reply]

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

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.

[reply]