hi Stas,
On Wed, Jul 18, 2012 at 6:35 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > >> enough but I don't know the Zend engine well enough). This way we can >> have array->key, array->sort(TYPE), etc. for new code to use, instead of >> the legacy array and string method mess (the latter needs a cleanup more >> in particular). > > The mess does not exist because we have array_key() instead of > array->key(). There's nothing wrong with having array_key(). The mess > exists because functions do not form single API with single principle > behind it, but were added in ad-hoc manner, sometimes without > correlating them with others. So, if you want to clean it up, you'd want > to write a plan how new API would look like and how it will be better > than old one. If the solution is "let's use ->" then it's not worth it. > The solution that's worth it is "let's have this better API" and that's > where we should start, not with changing array_key() to array->key() and > saying "now we have clean sexy API". > Please let me refresh the psat years history of PHP releases. Any attempt to change any kind of function signatures in the core has been rejected for obvious reasons (BC breaks, useless code changes, etc. etc.). So I won't spend a single second to try to propose to rewamp or duplicate functions for the sake of making the signature more consistent with each other, or cleaner. On the hand, this solution allows that, right away, without BC breaks and brings us to the (very) long term goal (actual object for standard types, like in other languages). Now you can totally disregard the benefit of this (purely vaporware right now) solution, but to keep saying that this argument is pointless is not going to bring us any step further, really not. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
