hi Rasmus, On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> 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. With all respects, this has nothing to do with a shiny new feature. The opcode cache support is actually a problem, I'd to agree. While we (my team and I) do more maintenance around the opcode area with APC (read: not the opcode related area per itself, not enough time sadly), I cannot buy your argument. This feature has been requested since years, by many major projects, same for other long awaited features like annotations. We simply can't keep ignoring these requests, that's what kill us. About opcode cache complexity, I think apc per se is full of things we should simplify or drop as features to make the code base much smaller and much easier to test and valid, we have discussed that already and we disagreed. But this is a topic I really want to bring on the table before we even consider bringing it in core (see other requests about that). Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
