Re: Extending PEAR DB

From: Date: Thu, 26 Apr 2001 12:49:19 +0000
Subject: Re: Extending PEAR DB
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-326@lists.php.net to get a copy of this message
Stig Bakken <ssb@fast.no> wrote: > ["Benjamin R. Webb" <brwebb@transmuto.com>] >> > $obj = (object)$result->fetchRow(); >> >> > That being said, having a fetch mode for objects could be very useful >> > if you can specify what class or object to use. >> >> > - Stig >> >> > -- >> Stig, >> >> Did I understand correctly that you want to be able to cast a query >> result to an arbitrary object? I've been working out a way to do >> that in my head, but I don't want to put it to code if I misunderstood. >> >> I'm still not sure that we shouldn't put this in a seperate set of functions >> as it will break the consistant array return type. Thoughts? --- deleted example code --- > object or NULL. The cast won't change the error object of course, but > the NULL value will change to an empty object that you can test with > "sizeof(get_object_vars($o)) == 0". > - Stig Thanks for the example code, I'm glad to see that I was thinking in more or less the right direction. Now that I have the code to do pretty much everything I want to, I'm still asking myself the second question. Since you are the original author for DB you are the one to decide: should I create a new set of functions just to handle objects or should I set it up as DB_FETCHMODE_OBJECT? The fetchmode is probably better in the sense of reusing code and keeping the list of methods small however it will add another return type to every function that uses it. It will also require one extra optional paramater of an object type that should be returned. So, would it be more appropriate to add functions to manipulate objects? It's really your call, I can implament it either way. Thanks again, Ben

« previous php.pear.dev (#326) next »