Everything

php

a last plead

php.internals

Lukas Smith

19 years ago

Hi,

I just want to say once again that all hell is going to break loose once
we release 5.2.0 as stable thanks to the various fatal errors we are
adding for perfectly working code that breaks OO theory.

I am talking about this change:
http://marc.theaimsgroup.com/?l=php-dev&m=114734977430980&w=2

As well as the rewriting signatures when inheriting and whatever other
fatal errors we are adding to things that are not actually fatal. Please
for the love of PHP, make these E_STRICT or E_NOTICE. Otherwise we will
have an army of angry users that will dwarf the one we were facing with
PHP 4.4.

Now is the time to fix this before RC6.

regards,
Lukas

Pierre Joye

19 years ago

On Thu, 19 Oct 2006 23:26:42 +0200
lsmith@php.net (Lukas Kahwe Smith) wrote:

> Hi,
>
> I just want to say once again that all hell is going to break loose
> once we release 5.2.0 as stable thanks to the various fatal errors we
> are adding for perfectly working code that breaks OO theory.
>
> I am talking about this change:
> http://marc.theaimsgroup.com/?l=php-dev&m=114734977430980&w=2
>
> As well as the rewriting signatures when inheriting and whatever
> other fatal errors we are adding to things that are not actually
> fatal. Please for the love of PHP, make these E_STRICT or E_NOTICE.
> Otherwise we will have an army of angry users that will dwarf the one
> we were facing with PHP 4.4.
>
> Now is the time to fix this before RC6.

+1 to move this one and all other related changes (if any remain) to
e_strict.

-- Pierre

Derick Rethans

19 years ago

On Thu, 19 Oct 2006, Pierre wrote:

> On Thu, 19 Oct 2006 23:26:42 +0200
> lsmith@php.net (Lukas Kahwe Smith) wrote:
>
> > I just want to say once again that all hell is going to break loose
> > once we release 5.2.0 as stable thanks to the various fatal errors we
> > are adding for perfectly working code that breaks OO theory.
> >
> > I am talking about this change:
> > http://marc.theaimsgroup.com/?l=php-dev&m=114734977430980&w=2
> >
> > As well as the rewriting signatures when inheriting and whatever
> > other fatal errors we are adding to things that are not actually
> > fatal. Please for the love of PHP, make these E_STRICT or E_NOTICE.
> > Otherwise we will have an army of angry users that will dwarf the one
> > we were facing with PHP 4.4.
> >
> > Now is the time to fix this before RC6.
>
> +1 to move this one and all other related changes (if any remain) to
> e_strict.

Yes, (ofcourse unless they can cause memory corruptions).

regards,
Derick

Christian Stocker

19 years ago

On 19.10.2006 23:26 Uhr, Lukas Kahwe Smith wrote:

> Hi,
>
> I just want to say once again that all hell is going to break loose once
> we release 5.2.0 as stable thanks to the various fatal errors we are
> adding for perfectly working code that breaks OO theory.
>
> Now is the time to fix this before RC6.

+1 too here.

It will IMHO slow down the adoption of 5.2, as - I assume - a
significant part of scripts will fatal out in 5.2. And this certainly
won't make all those people happy, who already had to rewrite their
programs for making them 5.0/1 compatible

chregu

--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 44 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | christian.stocker@bitflux.ch |  GPG 0x5CE1DECB

Glenn Richmond

19 years ago

Hmm, this is interesting - I just joined the mailing list, but I can
relate to this. I've come across a piece of code in that has the
following line in a function within a class:

return $this;

It seems to cause an over-allocation of memory and ultimately a seg
fault in both 5.1.4 and 5.2rc4, but works in 5.04. Is this the sort of
this that you're referring to?

Glenn.

Christian Stocker wrote:

Jasper Bryant-Greene

19 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Glenn,

'return $this' is perfectly acceptable and indeed very common code. It
works fine for me in 5.1.4 - you might like to report a bug if you can
reproduce a segfault...

What is being referred to here is things like 'abstract static'
functions that are completely meaningless from a theoretical point of
view (static functions are bound to the class they are defined on and do
not have inheritance rules so how can they be abstract?) but are still
being used by some people.

The argument is that we should not unnecessarily break these people's
code just because it makes no sense. Personally, I don't buy into this
argument. Perhaps if their code breaks and there is a good explanation
in the error message, they might start writing OO code that isn't
nonsensical.

Jasper


Glenn Richmond wrote:

> Hmm, this is interesting - I just joined the mailing list, but I can
> relate to this. I've come across a piece of code in that has the
> following line in a function within a class:
>
> return $this;
>
> It seems to cause an over-allocation of memory and ultimately a seg
> fault in both 5.1.4 and 5.2rc4, but works in 5.04. Is this the sort of
> this that you're referring to?
>
> Glenn.
>
> Christian Stocker wrote:
>> On 19.10.2006 23:26 Uhr, Lukas Kahwe Smith wrote:
>>
>>> Hi,
>>>
>>> I just want to say once again that all hell is going to break loose once
>>> we release 5.2.0 as stable thanks to the various fatal errors we are
>>> adding for perfectly working code that breaks OO theory.
>>>
>>> Now is the time to fix this before RC6.
>>>
>> +1 too here.
>>
>> It will IMHO slow down the adoption of 5.2, as - I assume - a
>> significant part of scripts will fatal out in 5.2. And this certainly
>> won't make all those people happy, who already had to rewrite their
>> programs for making them 5.0/1 compatible
>>
>> chregu
>>
>

- --
Jasper Bryant-Greene
Director
Album Limited

jasper@albumltd.co.nz
+64 21 708 334 / 0800 425 286
http://www.albumltd.co.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFcDBQFFOGq0nqZ4vwo6v1gRCv93AP40IC/FslI+O6BvPvSWwqQ8KzfJdZCoNxaW
Qufw5UC2NQEAmbXhhotg72ht80f1t0sL8SWiPfonq6zAFDwSNdi7Mnc=
=lMPv
-----END PGP SIGNATURE-----

Glenn Richmond

19 years ago

ok, sure. I'll be working to get more information on this one. I should
have said that the line of code where it crashes is called constantly.
It's part of a parent class and is almost the most called code in the
system. It's only when it's called via the SOAP interface for a
particular SOAP function that the error occurs.

I've been tracking down information on the issue just within PHP with
echo messages etc. However, what is the best method for getting detailed
info on the bug? Are there ways to get memory usage, stack trace etc? I
don't mind getting into the c code if required.

Glenn.

Jasper Bryant-Greene wrote:

Richard Quadling

19 years ago

On 20/10/06, Jasper Bryant-Greene <jasper@albumltd.co.nz> wrote:

> The argument is that we should not unnecessarily break these people's
> code just because it makes no sense. Personally, I don't buy into this
> argument. Perhaps if their code breaks and there is a good explanation
> in the error message, they might start writing OO code that isn't
> nonsensical.

I fully agree with the sentiment that Jasper and others are making here.

But I am torn between the purist and the pragmatic views.

Ideally, the PHP Object Model should be more or less set in stone.
Little or no choice for the user simply because choice is redundant
and devisive. The issue with this is WHICH object model to use - there
are many and not exactly the same.

As the upgrade will break some users' code because it is not
compatible or substandard in some way is a serious issue.

As always, the answer is education/information. Make it well known and
TRULY obvious what the issue is and WHY it has been changed well
BEFORE the release. Not tucked away in a release notice or a change
log which unless you where there at the time you have no idea what is
going on.

These sort of seemingly arbitary changes should be fully documented in
the manual and maybe even within the PHP runtime error reporting
system.

Say a new error reporting option which can provide a link to examples
of code and what should be changed and why. The why is the most
important part. If a PHP upgrade has just broken a user's code, that
user will want instant help in fixing it. What better than having a
proper description of the error and what to do to remove it.

Having an error for an upgrade and no explanation as to why it is now
an error is a pain as you don't know the consequences of changing the
code.

Richard.

--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731
"Standing on the shoulders of some very clever giants!"

Lester Caine

19 years ago

Richard Quadling wrote:

> Having an error for an upgrade and no explanation as to why it is now
> an error is a pain as you don't know the consequences of changing the
> code.

And the reason many providers are still running PHP4 and refuse to
provide PHP5 is partly wrapped in that statement.

Keep the esthic stuff for PHP6 and provide WELL DOCUMENTED support for
anything that is going to trash existing applications. We have been here
before and breaking good code is the main reason getting people to
upgrade is not happening ?

( And I STILL get ****ed by forgetting to 'copy all' :( )

--
Lester Caine - G8HFL
-----------------------------
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php

Wez Furlong

19 years ago

I agree.  Aside from making things difficult, these extra checks are
using up CPU cycles when we don't otherwise care about the "problems"
that are being highlighted.

I've been out of the loop for a couple of months, so I'm really
surprised that we've gotten all the way into late RC with such a
drastic change.

+1 for reducing the severity of these things.
+0 for taking the checks out.

--Wez.

On 10/19/06, Lukas Kahwe Smith <lsmith@php.net> wrote:

Greg Beaver

19 years ago

+1 for reducing severity to E_STRICT

Greg

Wez Furlong wrote:

Ilia A.

19 years ago

The check itself is done at compile time, so the CPU loss only
happens if you don't use an opcode cache, which means you probably
don't care much about the performance anyway :).

I definitely think we should keep the warning, but as you can tell
from my commit I do agree it should be reduced to E_STRICT.


On 20-Oct-06, at 8:27 AM, Wez Furlong wrote:

> I agree.  Aside from making things difficult, these extra checks are
> using up CPU cycles when we don't otherwise care about the "problems"
> that are being highlighted.
>
> I've been out of the loop for a couple of months, so I'm really
> surprised that we've gotten all the way into late RC with such a
> drastic change.
>
> +1 for reducing the severity of these things.
> +0 for taking the checks out.
>
> --Wez.
>
> On 10/19/06, Lukas Kahwe Smith <lsmith@php.net> wrote:
>> Hi,
>>
>> I just want to say once again that all hell is going to break
>> loose once
>> we release 5.2.0 as stable thanks to the various fatal errors we are
>> adding for perfectly working code that breaks OO theory.
>>
>> I am talking about this change:
>> http://marc.theaimsgroup.com/?l=php-dev&m=114734977430980&w=2
>>
>> As well as the rewriting signatures when inheriting and whatever
>> other
>> fatal errors we are adding to things that are not actually fatal.
>> Please
>> for the love of PHP, make these E_STRICT or E_NOTICE. Otherwise we
>> will
>> have an army of angry users that will dwarf the one we were facing
>> with
>> PHP 4.4.
>>
>> Now is the time to fix this before RC6.
>>
>> regards,
>> Lukas
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Ilia Alshanetsky