Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63677
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: <508C7F59.7000609@zerocue.com>
Date: Sat, 27 Oct 2012 19:42:01 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Patrick Schaaf <php@bof.de>
CC: internals@lists.php.net, Stas Malyshev <smalyshev@sugarcrm.com>
References: <508A67E6.2000405@zerocue.com> <CAJ26g5ScmGoW7uU4oFyNj21kX47DQqh1RDsZYo3SZV_7CHykQw@mail.gmail.com> <508C2267.2040205@zerocue.com> <1386509.9ZAIcfOWKR@rofl>
In-Reply-To: <1386509.9ZAIcfOWKR@rofl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method
 Visibility / Callability
From: cpriest@zerocue.com (Clint Priest)

Sounds like you're implying that the mere existence of a properly named 
function such as __prop_get_hours() would cause it to be called instead 
of returning the property.

There are several problems with this approach:

1) Currently __get() is only checked/invoked if there is not a property 
already defined; ie properties shadow __get() (no performance penalty)

2) It would dramatically reduce performance because every property 
access would have to create the function string, get it's hash value and 
do a hash look up against the function table, just to see if there is a 
properly named accessor function.  Failing that it would then check for 
the existence of a property and failing that move on to looking up __get

-Clint

On 10/27/2012 2:14 PM, Patrick Schaaf wrote:
> On Saturday 27 October 2012 13:05:27 Clint Priest wrote:
>> That's why I think they shouldn't even be visible to users, they aren't
>> relevant to them and in fact it could mis-lead them into thinking that
>> they could simply define __getHours() and expect $foo->Hours to call
>> it, which it wouldn't.
> I would expect / want it to do so.
>
> I see it this way:
>
> Defining semantics for magic methods named __prop_get_XXX, __prop_set_XXX etc
> as a specialization of __get/__set used whenever they exist for a given $XXX,
> is in my eyes a complete, proper accessor enhancement, saving me from doing a
> switch dance in __get/__set. The implementation should be absolutely
> straightforward, in the place where a missing property now tests for existence
> of __get/__set, a first, additional test for the specifically named
> __prop_get_XXX method would be added.
>
> Your proposed accessor _syntax_ is purely syntactic sugar, implementable on
> top of the functionality of the previous paragraph and implemented in terms of
> automatic code generation for it. This syntactic sugar could be separately
> implemented, discussed in a separate RFC,etc.
>
> The added complexity that I see, and I think Stas has meant to mention a lot
> of times, is everything - all code and documentation and explanation - that
> stems from NOT making it that two-step process. And in my opinion that would
> be completely superfluous, as it brings neither functionality nor syntax, just
> random additional issues.
>
> best regards
>    Patrick
>

-- 
-Clint