Stop Breaking Our Apps For the Sake of OO View as Markdown

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

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

Pierre wrote:

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.

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

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

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:

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

Best regards,
Marcus

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

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