Re: [PEPr] Proposal for Database::DB_Table
| From: | Paul M Jones | Date: | Wed, 07 Jan 2004 15:50:16 +0000 |
| Subject: | Re: [PEPr] Proposal for Database::DB_Table | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-24852@lists.php.net to get a copy of this message | ||
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. To meet your point, though, perhaps I can implement an "error" property that tracks construction errors. Would that be acceptable?
DB_TABLE_SELECT/DISTINCT constants seem to do very little - using the actually strings seemed to be more clear..Are you saying: instead of setting DB_TABLE_SELECT => 'fld1, fld2, fld3' and DB_TABLE_DISTINCT => true, use DB_TABLE_SELECT => 'DISTINCT fld1, fld2, fld3'? If so, I agree -- I can make that change immediately. (The separate distinct keyword is a holdover from when I used an array of fields the select keyword.) Sorry, I snipped out the portions of your mail that seem to refer to DB_Databobject (and the nonexistent M/DB_Schema). Did I miss any of the other DB_Table specific points? If so, I can address them. If there are no other points, though, are my changes enough to warrant your vote when the time comes? *** In general, though, you seem to be saying that DB_DataObjects "does all this already", and in a way it does -- although, as I have stated, I believe the operating philosophies of DB_DataObject and DB_Table are significantly divergent, thus adding the functions to DB_DataObject is not to me viable. 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. -- Paul M. Jones pmjones@ciaweb.net Savant: the simple alternative to Smarty. http://phpsavant.com/