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

Paul M Jones wrote:

Hi,

There are a few flaws with the design of DB_Table that I notice when looking through it. __construct can assign $this = $someclass.. = setting $this is not recommended in PHP or PEAR (the feature may be removed at some point) = normal practice is to use a factory method if you need to do things like this.

Understood. My problem is, I have found factory methods make it difficult to extend a class directly; in general, with a factory method, you need to write a new class file to return to the factory method. This is not, to me, friendly or "truly" extensible behavior.

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..) :) DataObject's factory does - enable extended classes in alot of ways - an now creates the proxy class on the fly...

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 = ....', ); ** although dataobjects uses lowercase for these ... 'select'/'where'

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..) Regards Alan -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com