Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44136
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <3949706BB9424F7FAC5AC708A01119DB@pc>
To: <internals@lists.php.net>
Date: Wed, 3 Jun 2009 23:48:53 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0023_01C9E4A5.D9B4A080"
Subject: Test for edge cases with __get and property access flags
From: sv_forums@fmethod.com ("Stan Vassilev")

------=_NextPart_000_0023_01C9E4A5.D9B4A080
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable


Hi,

I created a test that covers the current behavior of __get and access =
flags in some edge cases:
http://pastebin.com/d2ad892f5

Those are:

1. When a property is declared, but then unset via unset($this->foo), =
__get will be called.
2. When a property is declared private/protected, then unset and set =
again, it remains with the same access flags as originally declared =
(i.e. a private property remains private when set again).
3. When the caller tries to retrieve $object->foo, and foo is a =
private/protected member the caller has no access to, instead of an =
error, __get is called.

I'm not very sure the current behavior on item 3 is the best one (maybe =
error should be thrown regardless?), but freezing on either would be =
better than leaving it undefined :)

My request is that the behaviors tested here are either improved for =
correctness, or freezed as is. And then this test, or modified version =
of it, is added to the PHP source code to faciliate that. Thanks.

Regards,=20
Stan Vassilev 
------=_NextPart_000_0023_01C9E4A5.D9B4A080--