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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
