Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65118
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: <5100172C.8040903@zerocue.com>
References: <50F840F4.7080704@zerocue.com>
	<50FE7579.1010409@zerocue.com>
	<CAL+t6cGBxTRX_ZYvzX6RP=wLDaSzths_DVTdMKe3NBcccoeavw@mail.gmail.com>
	<CAAyV7nFo5v9bgnnRO=u+rWVvkvoqZwtOYPwNBU-MfOzLW115PQ@mail.gmail.com>
	<CAL+t6cF7=RX37F3Shgu1YjCgY0qM2NCG=YWKu73VkZpzcpRksQ@mail.gmail.com>
	<5100172C.8040903@zerocue.com>
Date: Wed, 23 Jan 2013 13:53:04 -0500
Message-ID: <CAL+t6cHmJpuSdhOzszY2nAw7MvH6i5Sn5vMsimasWWDTTiOWyg@mail.gmail.com>
To: Clint Priest <cpriest@zerocue.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec55550345669d504d3f93416
Subject: Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
From: theanomaly.is@gmail.com (Sherif Ramadan)

--bcaec55550345669d504d3f93416
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 23, 2013 at 12:00 PM, Clint Priest <cpriest@zerocue.com> wrote:

>
> Actually you could say that last sentence is precisely opposite of the
> truth in that a var_dump() will *never* expose properties that are
> available via a magic __get() therefore a var_dump() already mis-leads the
> developer because there can be properties that can be retrieved which are
> not shown by a simple var_dump().


They're not shown because they don't exist. Thus no confusion about whether
this is a property or not. If it's a property we can see it in
var_dump($obj). If it's magic you can only see it in
var_dump($obj->property). With accessors you see both, but you are seeing
(potentially) two different values. For me, that's the "misleading" part.

I agree that there are benefits here, but I can't agree that the benefits
outweigh the draw backs for me, which are all the added complexity. Like
Anthony said it's pretty much just coming down to custom scoping
getters/setters at the end of the day.




>
> The result of the current RFC is a result of the endless discussion that
> was had on this topic.  It's really not appropriate to vote against
> something if you did not make your voice heard when discussions of some
> aspect were happening.


I made my voice heard on the aspect that I was concerned with. My decision
was based on reading the entire RFC, downloading the patch, compiling the
code, testing it myself, and weighing the pros and cons of the proposal. I
believe I was pretty fair, but I am just one person of many that voted.

--bcaec55550345669d504d3f93416--