Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65094
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: <50FF0455.20501@zerocue.com>
Date: Tue, 22 Jan 2013 15:27:49 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <50F840F4.7080704@zerocue.com> <50FE7579.1010409@zerocue.com> <50FECA4E.6080408@lerdorf.com>
In-Reply-To: <50FECA4E.6080408@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
From: cpriest@zerocue.com (Clint Priest)

On 1/22/2013 11:20 AM, Rasmus Lerdorf wrote:
> On 01/22/2013 03:18 AM, Clint Priest wrote:
>>
>> For those that have voted against this proposal, are there any
>> clarifications that can be made or questions answered?
>>
>> There seems to be a lot of userland support for this proposal from
>> people who don't have voting rights.
> The simple explanation from me is that the ROI isn't there on this one.
> It adds a lot of code complexity for very little return. Yes, it saves a
> couple of lines of boilerplate code for a few people, but the cost is
> high in terms of ongoing maintenance and potential issues for opcode
> caches as well. If you look at the split in voting you will notice it is
> pretty much split along the lines of the people who have to maintain
> this code vs. the people who would like a shiny new feature.
Hey Rasmus,

With all due respect, I think you missed the post where Nikita Popov 
analysed two of the biggest PHP based frameworks around, Symfony 
(Standard) and Zend Framework where he found that there were 3,805 and 
4,080 functions which served as a getter or a setter.  I do not think 
his analysis even included any usage of __get() or __set(). Here is his 
original gist of his analysis:

https://gist.github.com/3884203

In terms of cost of maintenance, I was under the impression that since I 
wrote it, I would be maintaining it which is why I applied for and you 
approved a VCS account for me.

Lastly, I'm not sure if you have looked over the code, but a very large 
amount of duplicate code has been cleaned up and centralized, both 
property accessors and magic accessors use the same pre/post function 
and logic.  I can honestly say that adding the feature to the project 
would *improve* the code base.
> -Rasmus
>

-- 
-Clint