[tpm] eval oddness

[Stuart Watt]

Shaun Fryer wrote:
> as a general rule though, it's best to avoid "implementation 
> inheritance" ("use base", "push @ISA", "use parent") as much as 
> humanly possible. if at all possible it's much better in practice to 
> use "interface inheritance" ["use Module qw( some interfaces to import 
> )"]. inheritance is intrinsic to OOP, so it's important to understand 
> the design patterns associated with it and the pros and cons of each.
These are interesting points, but can I suggest you maybe went a little 
far with the "as much as humanly possible" bit. "as much as is 
appropriate to your purpose" would perhaps be better. (I'd suggest this 
is the core of quality - fitness for purpose.)

Inheritance is not completely intrinsic to OO - there are OO languages 
without inheritance (e.g., Self) and with limited concepts of 
inheritance (e.g., JavaScript). OO is really about being to build 
effective pieces of abstract behaviour. That is, you can hide internal 
implementation details, and still provide a service to others.

I'd say it all depends on what your purpose is. If you are writing code 
to be used by others, rather than writing code to be extended by others, 
you typically end up with different structures. If you want your code to 
be extended by others, inheritance is kind of invaluable. Most 
frameworks for extension provide many classes you can extend. Catalyst 
is a great example. DBI is a good contrast: you rarely benefit from 
extending database access provision, so a well-defined interface is a 
better choice.

Moose makes much of this a lot better, as it adds a few very helpful 
concepts, such as roles. Having used at least five different OO systems 
over the years, Moose is probably the one I've had most control over my 
application architecture with.

Just a few thoughts,

All the best
Stuart