abstract class ActiveRecord {
abstract static public function getTable();
static public function find() {
echo self::getTable();
}
}
class Person extends ActiveRecord {
static public function getTable() {
return __CLASS__;
}
}
Person::find();
Fatal error: Cannot call abstract method ActiveRecord::getTable() in /home/jhendric/test.php on line 7
Call Stack:
0.0004 40688 1. {main}() /home/jhendric/test.php:0
0.0005 40688 2. ActiveRecord::find() /home/jhendric/test.php:20
On 9/28/06,
Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote:
-- 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/
