Re: Stop Breaking Our Apps For the Sake of OO

From: Date: Thu, 11 May 2006 18:36:05 +0000
Subject: Re: Stop Breaking Our Apps For the Sake of OO
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hello Derick,

Thursday, May 11, 2006, 2:15:53 PM, you wrote:

> Hello!

> While I welcome new developments in either procedural or OO interfaces 
> in PHP I do not agree with breaking BC (between 5.1 and 5.2 in this 
> case) just for the sake of OO purity. In this example there is the 
> following class:

> <?php
> abstract class ezcDbHandler extends PDO
> {
>     public function __construct( $dbParams, $dsn )
>     {
>         $user          = null;
>         $pass          = null;
>         $driverOptions = null;
>     }

>     abstract static public function getName();

>     static public function hasFeature( $feature )
>     {
>         return false;
>     }
> }
?>>

It simply makes no sense at all! Actually if we go that road then what you
really want is two things: First fix your app design to something usable
where your code makes sense</sorry> Second allow static method interfaces
with bodies as well as non static abstract function in classes that have
bodies (aka default implementations).

> which now with PHP 5.2 throws:

>         derick@kossu:/home/httpd/ezcomponents/trunk$ php-5.2dev -l /tmp/foo42.php

>         Fatal error: Static function ezcDbHandler::getName() cannot be
> abstract in /tmp/foo42.php on line 11
>         Errors parsing /tmp/foo42.php

> And it works fine in PHP 5.1.

It simply is a missing error condition and hadn't we just closed 5.1 i would
add that missing check to 5.1 too.

> Now I know that abstract static might not 
> make much sense OO wise, but it doesn't hurt a single bit to have it 
> here. Breaking this just because it isn't OO enough is just bogus. So, 
> when are we going to remove this check so that older apps work again?

> regards,
> Derick




Best regards,
 Marcus


Thread (33 messages)

« previous php.internals (#23260) next »