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:
- When a property is declared, but then unset via unset($this->foo), __get will be called.
- 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).
- 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,
Stan Vassilev
2009/6/4 Stan Vassilev sv_forums@fmethod.com
- 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 :)
I always thought that this is the supposed behaviour. I believe I even
relied on it in one of my projects
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
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 :)
I always thought that this is the supposed behaviour. I believe I even relied on it in one of my projects
Hi,
If the community wants it like it is, then I'm just fine with that: as long as the test is committed, so that it doesn't change overnight. Any volunteers :)?
Regards,
Stan Vassilev
I thought this was the expected behaviour as well and I am quite sure that
I've used it in an experiment (all class members private and _get() output
escapes them) that failed pretty miserably. But I did think this was the
expected behavior. Perhaps it ought to throw an E_STRICT?
- 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 :)I always thought that this is the supposed behaviour. I believe I even
relied on it in one of my projectsHi,
If the community wants it like it is, then I'm just fine with that: as long
as the test is committed, so that it doesn't change overnight. Any
volunteers :)?Regards,
Stan Vassilev
Here's that test. I don't have commit rights to that area of CVS so
someone will need to do it for me.
John Mertic
jmertic@php.net
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 :)I always thought that this is the supposed behaviour. I believe I even relied on it in one of my projects
Hi,
If the community wants it like it is, then I'm just fine with that: as long as the test is committed, so that it doesn't change overnight. Any volunteers :)?
Regards,
Stan Vassilev