a last plead View as Markdown

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:

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:

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/

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