# Stop Breaking Our Apps For the Sake of OO

- Thread: https://externals.io/message/23242
- Original archive: https://news-web.php.net/php.internals/23242
- Started by Derick Rethans on 2006-05-11T12:15:53+00:00
- Messages: 15
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #23242 — Derick Rethans — 2006-05-11T12:15:53+00:00

URL: https://externals.io/message/23242#23242

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;
    }
}
?>

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. 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

---

## #23244 — Pierre — 2006-05-11T12:33:36+00:00

URL: https://externals.io/message/23242#23244 · In reply to: #23242

On Thu, 11 May 2006 14:15:53 +0200 (CEST)
derick@php.net (Derick Rethans) 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.

... or any other reason but security or critical bug.

As I already said many times, I disagree with the (recent) attitude to
break things in minor releases (no matter which things). 

We have added an `E_STRICT` mode, such changes should raise a notice in
 `E_STRICT` and be what it should be in the next major version. However,
if the error/notice is only about purity, it should not be added.
Purists may use other languages.

-- Pierre

---

## #23245 — Pierre — 2006-05-11T12:37:20+00:00

URL: https://externals.io/message/23242#23245 · In reply to: #23242

On Thu, 11 May 2006 14:15:53 +0200 (CEST)
derick@php.net (Derick Rethans) 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:

I forgot to mention how vicious such changes can be. Most of times the
related tests are "updated" in the same commit (or right after) to
follow the new behavior. Making nearly impossible to know about the
breakages without duplicating core tests in our apps. Also commit
messages or changelog entries are rarely explicit enough to mention
them.

-- Pierre

---

## #23246 — Sebastian Bergmann — 2006-05-11T12:47:00+00:00

URL: https://externals.io/message/23242#23246 · In reply to: #23245

Pierre wrote:
> I forgot to mention how vicious such changes can be. Most of times the
> related tests are "updated" in the same commit (or right after) to
> follow the new behavior. Making nearly impossible to know about the
> breakages without duplicating core tests in our apps. Also commit
> messages or changelog entries are rarely explicit enough to mention
> them.

 Maybe we could set up a testing system that runs the tests from PHP_4_4,
 PHP_5_0, PHP_5_1, and HEAD and shows the differences? That way we would
 notice that a test that passed with a previous version fails with a
 newer one.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

---

## #23248 — Derick Rethans — 2006-05-11T14:07:01+00:00

URL: https://externals.io/message/23242#23248 · In reply to: #23242

> 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:

<snip>

I've one more of those things. How to test if you're using PHP 5.1 or 
PHP 5.2:

<?php

class Bla
{
}

$b = new Bla;

if( $b != null )
{
        echo "PHP 5.1";
}
else
{
        echo "PHP 5.2";
}
?>

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #23249 — Lukas Smith — 2006-05-11T14:22:36+00:00

URL: https://externals.io/message/23242#23249 · In reply to: #23245

Pierre wrote:
> On Thu, 11 May 2006 14:15:53 +0200 (CEST)
> derick@php.net (Derick Rethans) wrote:
> 
> > […]
> 
> I forgot to mention how vicious such changes can be. Most of times the
> related tests are "updated" in the same commit (or right after) to
> follow the new behavior. Making nearly impossible to know about the
> breakages without duplicating core tests in our apps. Also commit
> messages or changelog entries are rarely explicit enough to mention
> them.

Yeah, modifications that require changes to existing tests due to BC 
breakage should get a clear label in the NEWS file that makes it clear 
that its a BC break. Otherwise things slip through the radar unnoticed 
or the scope of the change is never put to discussion.

regards,
Lukas

---

## #23253 — bertrand Gugger — 2006-05-11T15:39:30+00:00

URL: https://externals.io/message/23242#23253 · In reply to: #23245

Pierre wrote:
> I forgot to mention how vicious such changes can be. Most of times the
> related tests are "updated" in the same commit (or right after) to
> follow the new behavior. Making nearly impossible to know about the
> breakages without duplicating core tests in our apps. Also commit
> messages or changelog entries are rarely explicit enough to mention
> them.
a big +1
-- 
toggg

---

## #23255 — Richard Lynch — 2006-05-11T18:11:02+00:00

URL: https://externals.io/message/23242#23255 · In reply to: #23246

>  Maybe we could set up a testing system that runs the tests from
> PHP_4_4,
>  PHP_5_0, PHP_5_1, and HEAD and shows the differences? That way we
> would
>  notice that a test that passed with a previous version fails with a
>  newer one.

+1

-- 
Like Music?
http://l-i-e.com/artists.htm

---

## #23260 — Marcus Boerger — 2006-05-11T18:36:05+00:00

URL: https://externals.io/message/23242#23260 · In reply to: #23242

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

---

## #23261 — Marcus Boerger — 2006-05-11T18:38:22+00:00

URL: https://externals.io/message/23242#23261 · In reply to: #23248

Hello guys,

  sorry but i worked >12 hours on patch that brought half of the todo list
for 5.2 because all that stuff is unluckily interlinked.....and guess i can
make changes in a dev tree as well as there might be errors in head and i
even more might copy errors from head to the dev tree....too bad but why not
write a simple test case which i can care for?

Thursday, May 11, 2006, 4:07:01 PM, you wrote:

> 

> > […]

> <snip>

> I've one more of those things. How to test if you're using PHP 5.1 or 
> PHP 5.2:

> <?php

> class Bla
> {
> }

> $b = new Bla;

> if( $b != null )
> {
>         echo "PHP 5.1";
> }
> else
> {
>         echo "PHP 5.2";
> }
?>>

> regards,
> Derick

> -- 
> Derick Rethans
> http://derickrethans.nl | http://ez.no | http://xdebug.org




Best regards,
 Marcus

---

## #23262 — Pierre — 2006-05-11T19:29:38+00:00

URL: https://externals.io/message/23242#23262 · In reply to: #23260

> Hello Derick,
>
> Thursday, May 11, 2006, 2:15:53 PM, you wrote:
>
> > […]
>
> > […]
>
> > […]
>
> > […]
>
> > […]
> ?>>
>
> 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).

Marcus, I'm going to give you an unproducive answer again. First (and
despite your good work), I'm not really finding your answer anywhere
close from productive. To be honest, I even find it a bit arrogant and
respect less. I also have enough of your "fix your code" answer.

Second, your 300k patch is typically what I would consider as highly
dangerous. I'm not saying that each part of this patch are not
required, but it would have been better to commit smaller patches. For
example,  the zif to zim prefix changes, or to drop
ze1_compatibility_mode.

In the same area, commit to to extensions with "Methods have flags" as
message is nice, but who knows what you are talking about? I mean, how
should I know that 5.2 ZE2 internal APIs have changed? Yes, the API nr
has been bumped and there is a lot of new functions in your 300k
commit. Does it have any mention of the API changes (new
argument/breakage)? I do not see any.

So excuse me but I really find that annoying, even if I really
appreciate the fresh air you bring to the engine. Please consider to
inform us (php core developers, pecl developers) in the future and try
to make small patches instead of huge and unreadable patches. I have
to do it everytime I provided changes for something outside my
extensions, it is not that hard :-)

Thanks for your attention,

Cheers,

--Pierre

---

## #23270 — Marcus Boerger — 2006-05-11T19:51:02+00:00

URL: https://externals.io/message/23242#23270 · In reply to: #23262

Hello Pierre,

  only problem is, all that stuff is somehow dependend on one another.
I started with smaler chunks but it simply was not doable. Also we discussed
the changes for weeks if not to say for months. That a few things fail to
work is the lack of tests i already mentioned and also of cause the result
of a few mistakes i mindeed made.

regards
marcus

Thursday, May 11, 2006, 9:29:38 PM, you wrote:

> 
> > […]

> Marcus, I'm going to give you an unproducive answer again. First (and
> despite your good work), I'm not really finding your answer anywhere
> close from productive. To be honest, I even find it a bit arrogant and
> respect less. I also have enough of your "fix your code" answer.

> Second, your 300k patch is typically what I would consider as highly
> dangerous. I'm not saying that each part of this patch are not
> required, but it would have been better to commit smaller patches. For
> example,  the zif to zim prefix changes, or to drop
> ze1_compatibility_mode.

> In the same area, commit to to extensions with "Methods have flags" as
> message is nice, but who knows what you are talking about? I mean, how
> should I know that 5.2 ZE2 internal APIs have changed? Yes, the API nr
> has been bumped and there is a lot of new functions in your 300k
> commit. Does it have any mention of the API changes (new
> argument/breakage)? I do not see any.

This is a dev tree for now and we will change the API a few times more.
Once we are in fix phase it makes sense to find out the differences.
Until then we always lived very good by having ppl take care about all
they can compile. For example this means that i care for ~75 extensions
when doing that big changes.

> So excuse me but I really find that annoying, even if I really
> appreciate the fresh air you bring to the engine. Please consider to
> inform us (php core developers, pecl developers) in the future and try
> to make small patches instead of huge and unreadable patches. I have
> to do it everytime I provided changes for something outside my
> extensions, it is not that hard :-)

> Thanks for your attention,

> Cheers,

> --Pierre




Best regards,
 Marcus

---

## #23275 — Pierre — 2006-05-11T20:14:24+00:00

URL: https://externals.io/message/23242#23275 · In reply to: #23270

> Hello Pierre,
>
> only problem is, all that stuff is somehow dependend on one another.  I started with
> smaler chunks but it simply was not doable.

Well, I see many parts that should have been commited separatelly.

>Also we discussed the changes for weeks if not to say for months.

The needs to inform us and to clearly report changes remain.

> That a few things fail to work is the lack of tests i already mentioned and
> also of cause the result of a few mistakes i mindeed made.

I do not talk about the few things failing but breakages, api changes
and other annoyances (required or not.

Best regard,

--Pierre

---

## #23295 — dz@bitxtender.com — 2006-05-12T08:18:01+00:00

URL: https://externals.io/message/23242#23295 · In reply to: #23244

> As I already said many times, I disagree with the (recent) attitude to
> break things in minor releases (no matter which things).
>
> We have added an `E_STRICT` mode, such changes should raise a notice in
> `E_STRICT` and be what it should be in the next major version. However,
> if the error/notice is only about purity, it should not be added.
> Purists may use other languages.
>
> -- Pierre

I second that. Breaking BC in minor releases is nonsense.

- David

---

## #23297 — Derick Rethans — 2006-05-12T10:03:37+00:00

URL: https://externals.io/message/23242#23297 · In reply to: #23261

> Hello guys,
> 
>   sorry but i worked >12 hours on patch that brought half of the todo list
> for 5.2 because all that stuff is unluckily interlinked.....and guess i can
> make changes in a dev tree as well as there might be errors in head and i
> even more might copy errors from head to the dev tree....too bad but why not
> write a simple test case which i can care for?

I just added those.

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org