Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"

[prev] [thread] [next] [Date index for 2005/07/26]

From: Michael G Schwern
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 00:26 on 26 Jul 2005
On Tue, Jul 26, 2005 at 12:55:40AM +0100, Matt S Trout wrote:
> > *RATTLING CHAINS* Learn from my fate!
> 
> The following script lets me analyze the chain of whatever method I need to
> relatively easily

You're missing the point about what's wrong with mulitple inheritance.
Its not just about the ambiguity of what method will be called.  There's the
diamond inheritance problem.  There's the conceptual issue of inheriting
unrelated behaviors from N different subclasses, all which have to be
careful they don't share any public or protected method names.  There's 
accidental inheritance, inheriting a method or behavior you didn't intend on.
import() is a common example.  AUTOLOAD() from DynaLoader (and it from
AutoLoader).  CDBI has the problem of inheriting set() and get() from
Class::Accessor leaving no one else able to use it in conjunction with CDBI.
There's the brittleness of relying on inheritance order.

Most of these become internal issues for you because your inheritance
hierarchy is entirely under your control and the modules are (hopefully) used
by nobody else.  As long as you can manage them they won't get in anyone
else's way.  NEXT patches some of them up, but not others.

But there's the static nature of using MI to gain behavior rather than 
delegation.  Given the discussion about plug-ins this bears mentioning.

If I want to override, say, your SQL abstraction behavior... well I can't.
You've hard coded this behavior via inheritance.  If you were, instead, to
delegate this behavior to an SQL abstraction object and call methods on that
object you now allow anyone to write an SQL abstraction class with a similar
interface as yours and plop their object in place of yours.  Its flexible.
It avoids having to hack in a plug-in architecture later.

It allows you to more easily use somebody else's SQL abstraction module 
(like SQL::Abstract from which you borrowed code) instead of reinventing the 
wheel... again.  Part of the problem with Perl's persistance modules is they 
keep reinventing the same wheels over and over again repeating the same bugs, 
recoding the same features and needlessly dispursing effort.


        -- 
        Michael G Schwern     schwern@xxxxx.xxx     http://www.pobox.com/~schwern
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
	-- tchrist in <31832.969261130@chthon>

(message missing)

Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Michael G Schwern 00:26 on 26 Jul 2005

Delegation vs Hooks (was: Annouce: DBIx::Class, a.k.a "taking the easy way out")
=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= 23:27 on 26 Jul 2005

Generated at 16:36 on 28 Jul 2005 by mariachi v0.52