Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49901
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 209.85.213.42 cause and error)
Message-ID: <DECC2F93D1C44493AD9B9610567C45D6@pc>
To: <internals@lists.php.net>
Date: Tue, 12 Oct 2010 15:53:08 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0012_01CB6A25.90EF30C0"
Subject: Process failed? BC and use cases for property_exists() broken in PHP 5.3
From: sv_forums@fmethod.com ("Stan Vass")

------=_NextPart_000_0012_01CB6A25.90EF30C0
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

I think this is a great case study that could lead to some improvements =
in the process of fixing bugs in PHP:

http://bugs.php.net/bug.php?id=3D45743

A potential bug was reported on property_exists() that it won't report =
inaccessible properties in the scope.
The problem is this was, in fact, the intended behavior, and despite =
everything saying the function works correctly, everything around it was =
changed in order to agree with the new behavior for no good reason that =
I can see:

1) A test existed that specifically tested propert_exists() respects =
visibility of the property from the call scope. So for this 'bugfix' to =
pass tests, the *test was simply changed*.=20

2) The documentation specifically said the function respects visibility =
of the property, so for this 'bugfix' to agree with documentation, the =
*documentation was changed*.=20

3) The use case for this function required the existing behavior (i.e. =
can you safely call property $x from the current scope with no =
warning?), and that *ignored* when the behavior was changed. We already =
have Reflection classes for inquiring protected/private properties of a =
class from any scope.

So, what happened here?

Stan Vass
------=_NextPart_000_0012_01CB6A25.90EF30C0--