Re: Re: [PEPr] Proposal for Database::DB_Table

Hiya,

I cant remember the discussion on PHP5 dev, but I suspect they may raise a E_NOTICE in the future for doing this... on the presumption that it may be removed one day.. the problem being that $x = new TheClass(); should return TheClass, and not something else.. can you give a example of this problem - I've not seen any issues with factory methods in PHP.. - I have seen alot of problems with constructors however .. (mainly with gtk/reference stuff..) :)

Perfectly reasonable. I've given an example in my reply to Lukas' email; does that show you what I mean? Like I said there, I am willing to be shown how dumb I am. :-)

DB_TABLE_SELECT/DISTINCT constants seem to do very little - using the actually strings seemed to be more clear..

I was thinking $view = array( 'SELECT' => 'DISTINCT fld1,fld2,fld3', 'WHERE' => 'SOME_VAL = ....', );

That's what I thought, and I completely agree.

However, I'd like to argue the strengths of DB_Table by example, if you're willing. This might be the best way for me to show, either successfully or not, that DB_Table is a worthy contribution to PEAR.

What I'm trying do, is get most of the features of DB_Table implemented in DataObjects, enabling DB_Table just to be a simple function mapping wrapper around DataObjects... (either for BC, or an alterntive way to use the same class..)

If DB_Table code is to be merged with another package, I think the most appropriate place would be in DB proper (or as an additional class within DB proper). But that's just me, and of course it would require the approval of the DB guys (with a friendly "hello!" to Messrs Bakken, Cox, Hagenbuch, and Convissor). -- Paul M. Jones pmjones@ciaweb.net Savant: the simple alternative to Smarty. http://phpsavant.com/