Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64554
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mrclay.org from 50.22.11.19 cause and error)
Message-ID: <50E86BBB.2080104@mrclay.org>
Date: Sat, 05 Jan 2013 13:06:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: "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: steve@mrclay.org (Steve Clay)

On 1/3/13 5:43 PM, Stas Malyshev wrote:
> 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

Please ignore this if it's been debated before:

AFAICT C# strictly separates fields ("properties" in PHP) and properties (a set of 
accessors that emulate a field).

So the RFC provides 3 features (using C# terms):
1. A property API
2. A built-in storage variable so you don't need a separate field
3. Access to the storage variable as if it were a field of the same name

I think #2 is useful, avoiding the need to make a separate field just to make properties 
read-only or type-hinted. However I think the complexity and confusion we're running into 
is mostly caused by #3.

I think we might be better served by having another way to access this storage variable.

What if instead, we have the storage var available as $prop inside all the accessors? 
These would be the default implementations:

   get         { return $prop; }
   set($value) { $prop = $value; }
   isset       { return $prop !== NULL; }
   unset       { $prop = NULL; }

Pros:
* Makes clear that $prop is regular var access, and that $this->PropertyName *always* goes 
through accessors
* Gives isset/unset full access to the storage var, which allows doing things that can't 
be done via setter/getter. E.g. you could actually implement a property being "unset", 
which would be different from having it set to NULL.

Cons:
* Allows "evil", like having reads affect the storage var.
* Allows authors to hang themselves with recursive accessor calls, BUT those mistakes 
would be apparent from looking at the code.

What functionality possible in the RFC would be lost by this?

Steve Clay
-- 
http://www.mrclay.org/