Everything

php

Home » Project » Newsgroups » php.internals » Stop Breaking Our Apps For the Sake of OO »

Stop Breaking Our Apps For the Sake of OO

php.internals

Derick Rethans

20 years ago

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

Pierre Joye

20 years ago

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

David Zülke

20 years ago

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

20 years ago

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

Sebastian Bergmann

20 years ago

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

Jared Williams

20 years ago

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

Would have to diff the various tests too.
Perhaps the tests cases should never be removed, but the expected results altered so a diff between differing test suite versions
can show what behaviour has changed.

Jared

Marcus Börger

20 years ago

Hello Jared,

this is the first prodictive mail in this thread, we can easily
extend the .phpt system to have different expectations for different
versions of php. That was we can handle stuff that slightly changes
like spell correction in error messages and such.

Now not to you Jared but to all:
<complain@community>
However i said that already on IRC nobody is taking care on tests but
complain is what you guys are all goo at! Instead of screaming and
whining after a release you should write tests. When looking at <50%
coverage from a test run and @ <5K tests for a beast as big as php
that's a joke. So what to expect? Things change at will becuase we have
nothing to test against until somebody screams after a release....
</complain@community>

best regards
marcus

Thursday, May 11, 2006, 2:58:04 PM, you wrote:

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

> Would have to diff the various tests too.
> Perhaps the tests cases should never be removed, but the expected results
> altered so a diff between differing test suite versions
> can show what behaviour has changed.

> Jared

Best regards,
Marcus

bertrand Gugger

20 years ago

Bonsoir,
Marcus Boerger wrote:

> Hello Jared,
>
>  this is the first prodictive mail in this thread, we can easily
> extend the .phpt system to have different expectations for different
> versions of php. That was we can handle stuff that slightly changes
> like spell correction in error messages and such.
>
> Now not to you Jared but to all:
> <complain@community>
> However i said that already on IRC nobody is taking care on tests but
> complain is what you guys are all goo at! Instead of screaming and
> whining after a release you should write tests. When looking at <50%
> coverage from a test run and @ <5K tests for a beast as big as php
> that's a joke. So what to expect? Things change at will becuase we have
> nothing to test against until somebody screams after a release....
> </complain@community>

I look forward to run tests without having any idea of internal php.
Just it needs some infrastructure to do all of them.

Regards

--
toggg

Marcus Börger

20 years ago

Hello bertrand,

we already have an infrastructure that allows you to run tests.
Just do: make test

Thursday, May 11, 2006, 9:39:30 PM, you wrote:

> Bonsoir,
> Marcus Boerger wrote:
>> Hello Jared,
>>
>>  this is the first prodictive mail in this thread, we can easily
>> extend the .phpt system to have different expectations for different
>> versions of php. That was we can handle stuff that slightly changes
>> like spell correction in error messages and such.
>>
>> Now not to you Jared but to all:
>> <complain@community>
>> However i said that already on IRC nobody is taking care on tests but
>> complain is what you guys are all goo at! Instead of screaming and
>> whining after a release you should write tests. When looking at <50%
>> coverage from a test run and @ <5K tests for a beast as big as php
>> that's a joke. So what to expect? Things change at will becuase we have
>> nothing to test against until somebody screams after a release....
>> </complain@community>

> I look forward to run tests without having any idea of internal php.
> Just it needs some infrastructure to do all of them.

> Regards
> --
> toggg

Best regards,
Marcus

bertrand Gugger

20 years ago

Bonsoir
Marcus Boerger wrote:

> Hello bertrand,
>
>   we already have an infrastructure that allows you to run tests.
>   Just do: make test

I guess I was aware of that,
even if I'm more used to the pear format of .phpt
make test is easy
reporting failing ones is not
I just told I would try

Regards

--
toggg

bertrand Gugger

20 years ago

Marcus Boerger wrote:

> Hello bertrand,
>
>   we already have an infrastructure that allows you to run tests.
>   Just do: make test

I forgot the point:
I said infrastucture as what would need php to be complete ,
with a minimal build (with nothing) 45% of the tests are skipped.

Anyway, unit tests are only a first step ,
simulation brings much more , mock don't do it.

And as a tester , you should be idiot and have no idea what runs inside.

Regards

--
toggg

Marcus Börger

20 years ago

Hello bertrand,

one of the thinks i work on is this: http://gcov.php.net

Thursday, May 11, 2006, 11:57:09 PM, you wrote:

> Marcus Boerger wrote:
>> Hello bertrand,
>>
>>   we already have an infrastructure that allows you to run tests.
>>   Just do: make test
> I forgot the point:
> I said infrastucture as what would need php to be complete ,
> with a minimal build (with nothing) 45% of the tests are skipped.

> Anyway, unit tests are only a first step ,
> simulation brings much more , mock don't do it.

> And as a tester , you should be idiot and have no idea what runs inside.

> Regards
> --
> toggg

Best regards,
Marcus

Brian Moon

20 years ago

Marcus Boerger wrote:

> <complain@community>
> However i said that already on IRC nobody is taking care on tests but
> complain is what you guys are all goo at! Instead of screaming and
> whining after a release you should write tests. When looking at <50%
> coverage from a test run and @ <5K tests for a beast as big as php
> that's a joke. So what to expect? Things change at will becuase we have
> nothing to test against until somebody screams after a release....
> </complain@community>

How did this thread turn into complaining about tests?  The complaint
was about breaking working code.  I don't give a crap about tests.  I
want my code to work.  And, I believe that was the original point of
this thread.

--

Brian Moon
-------------
http://dealnews.com/
Its good to be cheap =)

Marcus Börger

20 years ago

Hello Brian,

sure i wanted to express to things. First 5.2 is work in (heavy) progress
and second that the lack of tests causes a bunch of unnecessary problems.
That said i ask everybody again to write tests for stuff he/she doesn't like
to change in case it hasn't been decided to change.

best regards
marcus

Thursday, May 11, 2006, 10:37:08 PM, you wrote:

> Marcus Boerger wrote:
>> <complain@community>
>> However i said that already on IRC nobody is taking care on tests but
>> complain is what you guys are all goo at! Instead of screaming and
>> whining after a release you should write tests. When looking at <50%
>> coverage from a test run and @ <5K tests for a beast as big as php
>> that's a joke. So what to expect? Things change at will becuase we have
>> nothing to test against until somebody screams after a release....
>> </complain@community>

> How did this thread turn into complaining about tests?  The complaint
> was about breaking working code.  I don't give a crap about tests.  I
> want my code to work.  And, I believe that was the original point of
> this thread.

> --

> Brian Moon
> -------------
> http://dealnews.com/
> Its good to be cheap =)

Best regards,
Marcus

Rasmus Lerdorf

20 years ago

Brian Moon wrote:

> Marcus Boerger wrote:
>> <complain@community>
>> However i said that already on IRC nobody is taking care on tests but
>> complain is what you guys are all goo at! Instead of screaming and
>> whining after a release you should write tests. When looking at <50%
>> coverage from a test run and @ <5K tests for a beast as big as php
>> that's a joke. So what to expect? Things change at will becuase we have
>> nothing to test against until somebody screams after a release....
>> </complain@community>
>
> How did this thread turn into complaining about tests?  The complaint
> was about breaking working code.  I don't give a crap about tests.  I
> want my code to work.  And, I believe that was the original point of
> this thread.

Marcus has a point here.  People are complaining loudly about bugs being
introduced.  These bugs would have been found quicker if we had better
tests.  If every complaint included a nice clean .phpt test file that
can be dropped right into the system, things would go a lot smoother.
Then the discussions can focus on those tests and how exactly we want
something to behave instead of people getting up in arms over things
that were obviously not intended to break.

-Rasmus

Richard Lynch

20 years ago

On Thu, May 11, 2006 3:58 pm, Rasmus Lerdorf wrote:

> Marcus has a point here.  People are complaining loudly about bugs
> being
> introduced.  These bugs would have been found quicker if we had better
> tests.  If every complaint included a nice clean .phpt test file that
> can be dropped right into the system, things would go a lot smoother.
> Then the discussions can focus on those tests and how exactly we want
> something to behave instead of people getting up in arms over things
> that were obviously not intended to break.

I also think it's important for .phpt files to not just disappear nor
be changed as a General Principle...

Regression testing against an ongoing body of QA tests is a Good
Thing, imho.

If a .phpt file HAS to be changed, in the sense of an intentional
change to the language, I'd actually prefer a NEW .phpt file -- so
that we KNOW the old test "breaks" in version X+1 but it should still
PASS in version X.

But that's just this naive reader...

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

Ilia A.

20 years ago

On 11-May-06, at 4:37 PM, Brian Moon wrote:

>
> How did this thread turn into complaining about tests?  The
> complaint was about breaking working code.  I don't give a crap
> about tests.  I want my code to work.  And, I believe that was the
> original point of this thread.
>

Complaining about your code not working does not earn you any brownie
points, either propose a patch to fix things or proactively develop
PHP tests that reflect your code so that when developers make changes
they can clearly see something was broken by the change.


Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

Jochem Maas

20 years ago

Some might consider the following a rant, personally
I just feel passionately about php and feel I need to speak up.
that you might consider it/me irrelevant or 'moany' is your
privelege - so with all due respect (

Ilia Alshanetsky wrote:

>
> On 11-May-06, at 4:37 PM, Brian Moon wrote:
>
>>
>> How did this thread turn into complaining about tests?  The  complaint
>> was about breaking working code.  I don't give a crap  about tests.  I
>> want my code to work.  And, I believe that was the  original point of
>> this thread.
>>
>
> Complaining about your code not working does not earn you any brownie
> points,

invalidating anything that crosses your path that seems to be (or is) a
complaint is IMHO shortsighted. IT is essentially a service industry,
dealing seriously with complaints in a professional and dignified manner
(regardless of how rude the 'customer' might be) is the difference between
success and failure.

the relationship between the developers (you) and the end users of php (me)
is symbiotic - both are required for a technology to be successful - with out
the success neither camps have a future earning money using the technology in
question.

As RM you might consider standing up for the interests of your endusers
a little more - they are after all the people that determine wheterh your releases
will be a success or not.

I don' buy the argument 'we do it for free, so don't complain' for the
simple reason that:

A. it's your own choice, doing something for free doesn't automatically
remove any/all responsibility which may come with the undertaken task.

B. nobody here is completely alturistic - both camps put effort in in order to
reap the rewards (be it financial, peer-status, whatever) for instance I can't
code C so I can't work on the engine but I can help other coders with their php
problems - so I post regularly on 'generals', I do this to increase php skills
of 'the community' in general (which adds to php programming's saleability) and to
learn more for myself (making me more saleable) and last but not least to share a
few laughs.

> either propose a patch to fix things or proactively develop  PHP
> tests that reflect your code so that when developers make changes  they

I suggest that some developers need show some restraint in making changes to
satisfy their own personal aesthetic tastes, any normal phper can live with someone
making a breaking change in order to fix an exotic segfault issue (or whateve) however
painful it might be, but forcing some purist OO crap on many people that breaks
existing code because one person thinks a certain way if the [only] correct way is
tantamount to project sabotage (it damages php's credibility which harms phpers across
the board).

trying hard not to breaking existing code (even when it grinds against ones' sense of
correctness) should be a higher priority that it has *seemingly* been in the past.

> can clearly see something was broken by the change.

submitting patches requires a level of skill which not everyone has - so basically
the 'rich' (people with good C skills) have a say and the rest can pretty much bend over.

submitting adequate tests again requires skills, resources, insight and knowledge
that most of us mere mortals don't possess - on top of which I would suggest that a
level of psychic ability is required to predict changes that only exist in some a
imaginary future which, again, most of us mere mortals don't possess.

in both the case for patches and tests submitting neither does anthing to relieve the
problem of breakages in released versions, and there are plenty of people out there
that are at the mercy of a sysadmin (or distro) with regard to what version they can
use.

regardless it *sounds* very much like your passing the buck, given that your
the RM I suggest the buck should probably stop with you.

kind regards,
Jochem

Richard Lynch

20 years ago

On Thu, May 11, 2006 7:47 am, Sebastian Bergmann wrote:

>  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

Lukas Smith

20 years ago

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

bertrand Gugger

20 years ago

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

Derick Rethans

20 years ago

On Thu, 11 May 2006, Derick Rethans 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

Jared Williams

20 years ago

> -----Original Message-----
> From: Derick Rethans [mailto:derick@php.net]
> Sent: 11 May 2006 15:07
> To: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Stop Breaking Our Apps For the Sake of OO
>
> On Thu, 11 May 2006, Derick Rethans 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";
> }
> ?>
>

Interesting logic break too...

$foo = new stdClass();
if ($foo == null || $foo != null) { echo 'Never gets echoed'; }

Jared

Jasper Bryant-Greene

20 years ago

Jared Williams wrote:

>
> Interesting logic break too...
>
> $foo = new stdClass();
> if ($foo == null || $foo != null) { echo 'Never gets echoed'; }

From a pure computer science point of view, the above makes complete
sense. Null means unknown value, so nothing is equal to it, not even
another null (because you don't know if the other null's *unknown* value
is equal to this null's *unknown* value). is_null() would make more
sense here.

Jasper

Jared Williams

20 years ago

>
> Jared Williams wrote:
> >
> > Interesting logic break too...
> >
> > $foo = new stdClass();
> > if ($foo == null || $foo != null) { echo 'Never gets echoed'; }
>
> From a pure computer science point of view, the above makes
> complete sense. Null means unknown value, so nothing is equal
> to it, not even another null (because you don't know if the
> other null's *unknown* value is equal to this null's
> *unknown* value). is_null() would make more sense here.

Yes, in certain languages tristate logic makes sense. But I don't think PHP is intended to be one of them.

Jared

Richard Lynch

20 years ago

On Thu, May 11, 2006 2:30 pm, Jasper Bryant-Greene wrote:

> Jared Williams wrote:
>>
>> Interesting logic break too...
>>
>> $foo = new stdClass();
>> if ($foo == null || $foo != null) { echo 'Never gets echoed'; }
>
> From a pure computer science point of view, the above makes complete
> sense. Null means unknown value, so nothing is equal to it, not even
> another null (because you don't know if the other null's *unknown*
> value
> is equal to this null's *unknown* value). is_null() would make more
> sense here.

With all due respect to the Mathematical theory behind that, it's just
asinine in a programming language I have to use every day.

Sorry.

:-)

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

Jasper Bryant-Greene

20 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Richard Lynch wrote:

> On Thu, May 11, 2006 2:30 pm, Jasper Bryant-Greene wrote:
>> From a pure computer science point of view, the above makes complete
>> sense. Null means unknown value, so nothing is equal to it, not even
>> another null (because you don't know if the other null's *unknown*
>> value
>> is equal to this null's *unknown* value). is_null() would make more
>> sense here.
>
> With all due respect to the Mathematical theory behind that, it's just
> asinine in a programming language I have to use every day.
>
> Sorry.

To be honest, I'd rather be able to compare nulls using equality in PHP
too. That kind of thing is exactly why I like PHP. I was just pointing
out the (probable) reasons behind the change - it's exactly the same as
having to use 'a IS NULL' instead of 'a = NULL' in MySQL etc.

Jasper
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEY6iNFfAeHhDzT4gRA0ArAKCRzAtRqfuscf4Y5B4KTOvCFg6HxwCg8LdJ
qxquURkKi8dIWgQvCm+LwP0=
=UeTH
-----END PGP SIGNATURE-----

Marcus Börger

20 years ago

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:

> On Thu, 11 May 2006, Derick Rethans 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

Derick Rethans

20 years ago

On Thu, 11 May 2006, Marcus Boerger wrote:

> 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

Marcus Börger

20 years ago

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

Pierre Joye

20 years ago

On 5/11/06, Marcus Boerger <helly@php.net> wrote:

> 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

Marcus Börger

20 years ago

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:

> On 5/11/06, Marcus Boerger <helly@php.net> wrote:
>> 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.

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

Pierre Joye

20 years ago

On 5/11/06, Marcus Boerger <helly@php.net> wrote:

> 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