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(). 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? : > 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). 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. 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. Some of this is just the way Apache::DBI has to work (it has to be a subclass of DBI to be a wrapper, and if you have two classes that inherit from the DBI, which do you choose, etc.), so it's not a complaint, but subclassing DBI and using it with Apache::DBI (or any other wrapper class) isn't as straightforward and intuitive as it could be, just like "subclassing DBI means subclassing DBI, DBI::db, and DBI::st" isn't as intuitive as it could be. And again, this is all user-level, not developer-level. From the developer standpoint, I could see how it would suck to have to work out those dependencies and inheritance chains, but from a user standpoint, it sucks trying to figure out how everything fits together. * Philip Molter * Texas.net Internet * http://www.texas.net/ * [EMAIL PROTECTED]
