Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64497
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
Message-ID: <50E566B1.6090106@zerocue.com>
Date: Thu, 03 Jan 2013 05:08:33 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>
References: <50E41BB6.4030901@zerocue.com> <50E4697D.9000008@mrclay.org> <50E4A1D9.1050901@zerocue.com>
In-Reply-To: <50E4A1D9.1050901@zerocue.com>
Content-Type: multipart/alternative;
 boundary="------------050403050900020509000705"
Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before
 Vote
From: cpriest@zerocue.com (Clint Priest)

--------------050403050900020509000705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------050403050900020509000705--