Just getting back to you on #1 and #2...
#1: It seems the majority want to have these internally created accessor
functions visible, which they presently are through get_class_methods,
etc. They are currently hidden by Reflection. I favor the latter, as is
implemented in Reflection since an accessor is "like a method" but is
not quite a method. At any rate, unless anyone voices support for
accessors being hidden from the non-reflection methods, then the current
Reflection changes regarding filtering them from getMethods() will go away.
One alternative here is that I could add a parameter to getMethods()
which would either filter or not filter accessors, which would let
whomever work the way they want to. Defaulting to... which way?
#2:
class a {
public $Foo {
get {
echo "Getting \$Foo, __FUNCTION__ = ".__FUNCTION__.",
__METHOD__ = ".__METHOD__.PHP_EOL;
return 5;
}
}
}
$o= new a();
echo $o->Foo;
Outputs:
Getting $Foo, __FUNCTION__ = __getFoo, __METHOD__ = a::__getFoo
5
I will add to the RFC that __FUNCTION__ and __METHOD__ work as expected.
On 1/2/2013 3:08 PM, Clint Priest wrote:
On 1/2/2013 11:08 AM, Steve Clay wrote:
A few remaining questions. The RFC makes it clear that
ReflectionClass::getMethods() does not return internal method names
like __setSeconds.
1. Are these names visible via get_class_methods() / method_exists()
/ is_callable()?
This is the only remaining point of contention but I would expect
however it is resolved, all methods of reflection would match.
2. Inside an accessor, what do __FUNCTION__ and __METHOD__ evaluate as?
I would have to test them but they are methods so they should evaluate
as you would expect, I'll test.
3. What happens if a class/subclass contains a regular method
__setSeconds?
Same thing as a duplicate function declaration error, since that's
what it is, remember that the prefix __ is reserved for php internal
use, if I recall correctly userland code should not be using a double
underscore.
Steve Clay
On 1/2/2013 11:41 AM, Steve Clay wrote:
The RFC does not specify whether it's a fatal error to define a class
(directly or via extends/traits) which has both a traditional
property and accessor with the same name, but I think this should be
prohibited to avoid confusion.
One might expect this to work if the traditional property is private
in a parent class, but I think even if the patch allowed that special
case (I've not tried it), it should not.
As of the current fork there is no difference between a property and a
property with accessors except that a property with accessors will
always route through the accessor methods. In other words a
property_info structure is created for either type.
Ergo, the same rules apply, a second declaration of a property with
the same name will cause a compilation error.
--
-Clint
