Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26120
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 64.233.166.178 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=d3URNehJrlB9F3l+T3D4nBrHmdttO3v5ZctSU/CILyOGwd2hBdiVIESoAz0uHeEp7Olt13rVUdTbQFYaym9S8Fr9ojDI9mCPf/Pz/IygR+CvCjLuty/dmBUf1r+fk6P6CDSe4eXMKqckCH728tDL/OIpLT4wht0t1HIONLBxiAc=
Message-ID: <10845a340610200043g7f6f6152tf91a53e37682d113@mail.gmail.com>
Date: Fri, 20 Oct 2006 08:43:09 +0100
Reply-To: RQuadling@GoogleMail.com
To: "Jasper Bryant-Greene" <jasper@albumltd.co.nz>
Cc: "Glenn Richmond" <glenn.richmond@ilisys.com.au>, 
	"Christian Stocker" <christian.stocker@bitflux.ch>, 
	"Lukas Kahwe Smith" <lsmith@php.net>, internals@lists.php.net
In-Reply-To: <45386AB4.60504@albumltd.co.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <18.FF.27040.69DE7354@pb1.pair.com> <453857D8.3020704@bitflux.ch>
	 <45385952.7040400@ilisys.com.au> <45386AB4.60504@albumltd.co.nz>
Subject: Re: [PHP-DEV] a last plead
From: rquadling@googlemail.com ("Richard Quadling")

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!"