RE: [PEAR-DEV] Re: [PEPr] Proposal for Database::DB_Table

> From: Paul M Jones [mailto:pmjones@ciaweb.net] > Sent: Wednesday, January 07, 2004 4:50 PM Note I havent looked at the proposal in detail. > > 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? The factory method can of course be defined in the actual class: class foo { Function __construct() { } Function factory() { } } > > 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.) I agree. Regards, Lukas