# a last plead

- Thread: https://externals.io/message/26097
- Original archive: https://news-web.php.net/php.internals/26097
- Started by Lukas Kahwe Smith on 2006-10-19T21:26:42+00:00
- Messages: 12
- 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

---

## #26097 — Lukas Kahwe Smith — 2006-10-19T21:26:42+00:00

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

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

---

## #26098 — Pierre — 2006-10-19T21:36:48+00:00

URL: https://externals.io/message/26097#26098 · In reply to: #26097

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

---

## #26104 — Christian Stocker — 2006-10-20T05:00:08+00:00

URL: https://externals.io/message/26097#26104 · In reply to: #26097

> 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

---

## #26105 — Glenn Richmond — 2006-10-20T05:06:26+00:00

URL: https://externals.io/message/26097#26105 · In reply to: #26104

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:
> 
>   
> > […]
>
> +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

---

## #26106 — Jasper Bryant-Greene — 2006-10-20T06:20:36+00:00

URL: https://externals.io/message/26097#26106 · In reply to: #26105

-----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:
> > […]
> 

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

---

## #26107 — Glenn Richmond — 2006-10-20T06:26:11+00:00

URL: https://externals.io/message/26097#26107 · In reply to: #26106

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:
> 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:
> > […]
> loose once
> > […]
>
> --
> Jasper Bryant-Greene
> Director
> Album Limited
>
> jasper@albumltd.co.nz
> +64 21 708 334 / 0800 425 286
> http://www.albumltd.co.nz/

---

## #26120 — Richard Quadling — 2006-10-20T07:43:09+00:00

URL: https://externals.io/message/26097#26120 · In reply to: #26106

> 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&r=213474731
"Standing on the shoulders of some very clever giants!"

---

## #26108 — Derick Rethans — 2006-10-20T08:09:19+00:00

URL: https://externals.io/message/26097#26108 · In reply to: #26098

> On Thu, 19 Oct 2006 23:26:42 +0200
> lsmith@php.net (Lukas Kahwe Smith) wrote:
> 
> > […]
> 
> +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

---

## #26121 — Lester Caine — 2006-10-20T12:26:34+00:00

URL: https://externals.io/message/26097#26121 · In reply to: #26120

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

---

## #26122 — Wez Furlong — 2006-10-20T12:27:18+00:00

URL: https://externals.io/message/26097#26122 · In reply to: #26097

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.


> 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

---

## #26127 — Gregory Beaver — 2006-10-20T14:01:04+00:00

URL: https://externals.io/message/26097#26127 · In reply to: #26122

+1 for reducing severity to `E_STRICT` 

Greg

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.
> 
> 
> > […]

---

## #26130 — Ilia Alshanetsky — 2006-10-20T14:19:34+00:00

URL: https://externals.io/message/26097#26130 · In reply to: #26122

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.




> 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.
>
> 
> > […]
>
> -- 
> 
> 
>
>

Ilia Alshanetsky