Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64486
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: <50E4A1D9.1050901@zerocue.com>
Date: Wed, 02 Jan 2013 15:08:41 -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>
In-Reply-To: <50E4697D.9000008@mrclay.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before
 Vote
From: cpriest@zerocue.com (Clint Priest)


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