Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64512
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: <50E63FFD.2020602@zerocue.com>
Date: Thu, 03 Jan 2013 20:35: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: Stas Malyshev <smalyshev@sugarcrm.com>
CC: Steve Clay <steve@mrclay.org>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <50E41BB6.4030901@zerocue.com> <CADEasVEHFOgC_f-YFHPu4JoWogLgjiLouNX55oQUgSDyLM_Ggg@mail.gmail.com> <50E4A43E.6030302@zerocue.com> <50E4B232.5000505@mrclay.org> <50E4BDDE.8050509@zerocue.com> <50E4D0BB.7060701@mrclay.org> <50E4FA09.7030001@zerocue.com> <50E529B6.1050903@sugarcrm.com> <50E593DF.9090004@mrclay.org> <50E60994.4000400@sugarcrm.com>
In-Reply-To: <50E60994.4000400@sugarcrm.com>
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)


Not really sure what to say about this, we can either guard against 
recursion or not, I see
no reason *not* to guard against recursion except that it could allow 
unauthorized direct
access when the guard is active.

I guess a third option could be that if the property is attempted to be 
accessed while
being guarded and that access is not from within the accessor, then it 
issues a warning (or not)
and returns NULL.

Thoughts?

On 1/3/2013 4:43 PM, Stas Malyshev wrote:
> Hi!
>
>> I think infinite recursion is a potential issue for lots of logging setups ("let's log
>> when someone calls the logger!") and situations where you have multiple values to keep in
>> sync. The accessor implementation shouldn't try to solve these design problems.
> The whole problem here is that the only reason why it is a problem is
> because of the accessors that have hidden state in guards. If it were
> regular variables (and for all the API consumer knows, they are) there
> wouldn't be any question about if we're allowed to read $user->username
> or not - if it's public, of course we can read it. So the problem exists
> because the hidden state exists. It's not the problem of the code that
> uses public APIs in completely legal way, it is the problem of our
> implementation that we have hidden state that changes how variable
> access works. With __get we mostly ignored it since recursion blocker
> leads to the same result as if the variable did not exist - which is the
> case for __get anyway, kind of - so it was less explicit. With accessors
> it may become more painful.

-- 
-Clint