Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65035
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50F8A88D.1000409@zerocue.com>
References: <50F840F4.7080704@zerocue.com>
	<50F87A23.60808@mrclay.org>
	<50F8A88D.1000409@zerocue.com>
Date: Sat, 19 Jan 2013 23:46:46 -0500
Message-ID: <CAL+t6cE4FGLpbYQfzkL=gzLefBefk2ntJDEhbiKx9niYBsh7uw@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: Steve Clay <steve@mrclay.org>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec55550342d38fd04d3b10806
Subject: Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
From: theanomaly.is@gmail.com (Sherif Ramadan)

--bcaec55550342d38fd04d3b10806
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 17, 2013 at 8:42 PM, Clint Priest <cpriest@zerocue.com> wrote:

>
> On 1/17/2013 4:24 PM, Steve Clay wrote:
>
>> > https://wiki.php.net/rfc/**propertygetsetsyntax-v1.2#**voting<https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting>
>>
>> I'll say my peace on this. This is a very good implementation, and as
>> long as authors use accessors that depend on a separate property for
>> storage (like other langs require), everything will be straightforward.
>> Otherwise, I fear they're in for some confusing behavior.
>>
>> Consider the code from the RFC:
>>
>> class TimePeriod {
>>     public $Hours {
>>         get { return $this->Hours ?: "not specified"; }
>>         set { $this->Hours = $value; }
>>     }
>> }
>>
>> $tp = new TimePeriod();
>> $tp->Hours; // "not specified"
>> isset($tp->Hours); // true!?
>>
>>  $tp->Hours isset, the property exists and it's value is non-null.
>
>
>  The auto implementation of isset compares $this->Hours to NULL, but since
>> $this->Hours goes through the getter, it will return "not specified". So
>> the property will always appear to be isset.
>>
>> * The guards seem spooky: A set of tokens ($this->prop) will have varying
>> behavior (e.g. direct prop read vs. getter call) *depending on the call
>> stack*.
>>
> This is the same as would occur with isset against an undefined property,
> that would call __isset(), followed by __get() which would then compare the
> value to NULL.
>
>
>> * Giving issetter/unsetter no direct access to the property limits
>> functionality and leads to weirdness like the example above.
>>
>>  This is possible, simply by supplying your own implementation of
> isset/unset that calls isset/unset, such as:
>
> public $foo {
>     get; set;
>     isset { return isset($this->foo); }
>     unset { unset($this->foo); }
> }
>
> The above five lines of code is exactly equivalent in functionality to:
>
> public $foo;
>
> -Clint
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I'm not sure if this has already come up in past discussion or not. So
I apologize in advance if this is repetitive. The discussion for property
accessors has been so lengthy I couldn't find the time to keep up with it
all.

However, I found some time to play around with the patch today and I
noticed something that might use improving. When you use var_dump() on the
object properties that have defined get accessors don't produce any useful
output with var_dump. Is this fixable?

--bcaec55550342d38fd04d3b10806--