-- Davey Shafik <[EMAIL PROTECTED]> wrote (on Thursday, 28 September 2006, 10:20 AM -0400): > And that'll teach me to jump in on a conversation :) > > What about implementing an interface which specifies a getTable() > method, then don't implement it in an Abstract AR class. > > That way when you extend, you write in a: > > function getTable() > { > return __CLASS__; > } > > or you can even do: > > function getTable() > { > return "Somethingcompletelydifferent"; > } > > I dislike this idea, I prefer just to instantiate the AR class and > use it as an object :)
This type of solution was discussed at one point. I believe it was rejected because many felt it added what could be construed as one step too many in development. Instead of simply: class MyTable extends Zend_Db_Table {} the developer now has to do: class MyTable extends Zend_Db_Table { public static function getTable() { return __CLASS__; } } Admittedly not a lot of code, but it's another vector for introducing errors. I'm not exactly sure where my own preference lies, personally. > On Sep 28, 2006, at 10:03 AM, Pavel Shevaev wrote: > > > On 9/28/06, Davey Shafik <[EMAIL PROTECTED]> wrote: > > > Uh.... > > > > > > __CLASS__ > > > > > > > Not really, here's how it all started > > http://www.sitepoint.com/forums/showthread.php?t=334377 -- Matthew Weier O'Phinney PHP Developer | [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/