On Fri, Jan 04, 2002 at 11:31:04AM -0600, Philip Molter wrote:
> On Fri, Jan 04, 2002 at 04:40:09PM +0000, Tim Bunce wrote:
> : On Fri, Jan 04, 2002 at 08:21:22AM -0600, Philip Molter wrote:
> : > On Thu, Jan 03, 2002 at 01:25:03AM +0000, Tim Bunce wrote:
> : >
> : > : Simply calling $dbh = MyDBI->connect(...) will be interpreted
> : > : as a request to have the $dbh blessed into the MyDBI::db class
> : > : (and a $dbh->prepare will return $sth blessed into MyDBI::st).
> : > : A warning will be generated if @MyDBI::db::ISA is empty.
> : >
> : > Will it automatically update @MyDBI::db::ISA in the process?
> :
> : Nope. It'll just ignore the subclass that's been incorrectly setup.
> : I think it's safer that way.
>
> Well, if the goal is to make DBI more easily subclassable, then I
> think it's a automatic subclasses is a worthy feature. Perhaps
> make it a runtime option. Honestly, I think something like that
> is a lot more important in terms of ease-of-use than eliminating
> __PACKAGE__->init_rootclass().
Consider your example in your previous message
WebDBI -> MyDBI -> DBI
If calling
WebDBI->connect(...)
setup @WebDBI::ISA to 'DBI::db', as your suggesting, then it would
be doing the wrong thing. If it only did that if @WebDBI::ISA was
empty then it might be 'better' but also 'inconsistant'.
> Perl often allows unsafe conditions and does it's best to still
> succeed. You can force safer conditions with 'use strict', of
> course, if that's what you want. In the spirit of perl, wouldn't
> it be nice if DBI worked the same way?
I think there different issues. And the DBI design has always put
a premium on safety.
Anyone not very comfortable with assigning to @ISA should not
be trying to subclass the DBI!
But having said that, it certainly could be made easier...
> : > That would make it a little easier for Apache::DBI to handle DBI
> : > subclasses, something which isn't impossible now, but is a little
> : > annoying.
> :
> : I'm not sure what you mean. Can you expand on that? (re subclassing
> : Apache::DBI)
>
> Perhaps it wouldn't make Apache::DBI any easier, but right now,
> the whole point of using Apache::DBI is that if it's loaded, it's
> supposed to intercept DBI usage and wrap it in Apache::DBI(::db|::st)
> calls. That's beautiful. It's the way it should work. If I load
> Apache::DBI in my mod_perl config, any one of my scripts, modules,
> what-have-you that uses DBI will really use Apache::DBI and get
> managed, persistent connections. Very elegant. Nothing ever needs
> to know if Apache::DBI even exists, in theory.
>
> I want to live in theory because everything works in theory.
>
> The problem comes with DBI (not Apache::DBI) subclasses. MyDBI,
> right now, uses init_rootclass, so Apache::DBI still intercepts
> the call, but the ::db instance you get back is really MyDBI::db,
> not Apache::DBI::db, because DBI re-blesses the final return into
> the root class. Thus, you lose the power of Apache::DBI's connection
> caching (and it introduces a host of other problems).
Ah yes. I've been aware that there's a need to handle the 'stacking'
of multiple subclasses in an elegant way - but I've not given it much
thought - beyond thinking I must take a look at the Class:: modules
and elsewhere for any the provide handy 'plumbing' mechanisms.
I also plan to chat with Damian during Perl Whirl in a couple of
weeks. I'm sure I'll come back from that with a clear view. I think
I already have some good and simple ideas. Basically a simple way
of saying "add this class as a subclass of the 'previous' DBI subclass"
is needed (plus a few bells-n-whistles).
> You can decide to not call init_rootclass(), which means the object
> you get back is an Apache::DBI::db instance, which inherits directly
> from DBI::db. Then you lose any enhancements you've made to the
> ::db and ::st classes.
>
> You can have your subclass inherit from Apache::DBI, but that sort
> of defeats the elegance of Apache::DBI, and requires your subclasses
> to have knowledge of distinctive environments. It's messy from a
> theoretical point of view, not necessarily an operational point of
> view. I would argue that the subclass is NOT a subclass of
> Apache::DBI, and the current schema forces it to to be one.
For the kind of stacking/layering of functionality that we're
talking about here then they are, and need to be, subclasses.
No need to discuss the finer points of semantics here.
> Perl's
> nice enough to make it work, but Apache::DBI is supposed to function
> as a transparent wrapper around DBI, not an object to be subclassed
> (unless you want to extend that wrapping). Furthermore, if you
> later want to do some other sort of DBI wrapper, you'll have to go
> to all your subclasses, and add a class to @ISA for it to work
> properly. So it's not transparent at all.
I see the need and plan to make it as transparent as possible.
It probably won't be in the next release but I'll try to address
it for the one after (nag me if I don't :)
Thanks.
Tim.
