Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64506
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: <50E5B4B4.50705@zerocue.com>
Date: Thu, 03 Jan 2013 10:41:24 -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: Steve Clay <steve@mrclay.org>
CC: 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> <50E56450.1060801@zerocue.com> <50E5A4DB.2000205@mrclay.org>
In-Reply-To: <50E5A4DB.2000205@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/3/2013 9:33 AM, Steve Clay wrote:
> On 1/3/13 5:58 AM, Clint Priest wrote:
>> class Foo {
>>      public $bar = 2 {
>>          get;
>>          set;
>>      }
>> }
>
> Consider properties not based on shadowed values:
>
> class Foo {
>     private $realbar;
>
>     public $bar = 2 {
>         get { return $this->realbar; }
>         set { $this->realbar = $value; }
>     }
> }
>
What would be the point of this?  Why not just do this:

class Foo {
     private $realbar = 2;

     public $bar {
         get { return $this->realbar; }
         set { $this->realbar = $value; }
     }
}

> Here, initializing the shadow property is useless. It's similar to the 
> case where you want to have the initial value of a traditional 
> property be the result of an expression (and you can't because it 
> would create a chicken-egg problem during construction).
>
>
> Option 1: The most powerful solution I see is to have an init function 
> that's implicitly called before first access (and with direct write 
> access to the shadow property if needed). Consider trying to emulate 
> the crazy document.cookie API:
>
> class Document {
>     private $cookieProps;
>
>     public $cookie {
>         get { return /* based on cookieProps */; }
>         set { /* set some cookieProps */ }
>
>         // called implicitly before the first access (not before the 
> constructor runs)
>         // and would have direct access to the shadow property.
>         init { /* set up cookieProps */ }
>     }
> }
>
> Pros: can run any code necessary to initialize the property
> Cons: must make a function just to have a default
>
>
> Option 2: Keep the traditional syntax, but instead of always setting 
> the shadow property, call the setter with the given initial value 
> directly before the first access.
>
> Pros: familiar syntax; more expected behavior in some cases
> Cons: what if there's no setter?; cannot run arbitrary setup code; 
> setter can't distinguish between a "user" set and the implicitly set 
> before first access.
>
>
> Option 3: A mix of both. The shadow property is always initialized 
> with the value from the traditional syntax. If needed, you can have an 
> init that's called before first access.
>
> Pros: For simple shadowed properties, just works as you'd expect and 
> with familiar syntax; Still allows robust initialization before first 
> access if needed.
> Cons: Author must remember that traditional syntax only useful for 
> shadow prop.
>
I like the idea of an init function, but that would have to wait for a 
further release I think, or delay this whole project a year.

Adding the ability to specify an = X value to a property with accessors 
would be trivial.
>
> Steve Clay

-- 
-Clint