On 25/01/2014 23:36, Yasuo Ohgaki wrote:
For example, I've made pg_query() long time ago while there was pg_exec().
http://jp2.php.net/manual/en/function.pg-query.php
At that time, there wasn't a prepared query. Now we have pg_execute() to execute
prepared query.
I guess not many people consider this was harmful.
I suppose most pgsql users are pleased these new names and aliases.
Actually, *most* pgsql users have probably never used half of those functions, and the other half are used once or twice in a rarely-edited abstraction layer, and if you asked someone how many underscores were in the names they would look it up in the manual. These are not the kind of functions usually mentioned regarding general consistency of function names - the examples given are often widely-used functions like string and array utilities.
These are going to be used all over the place in shared code, and applications supporting older versions of PHP will need to carry on using old names, applications migrating will have to decide if it's worth finding and replacing them all, and new applications will have to decide if the new names should be adopted as official coding standards, based on what other applications the coders are working on.
Adding aliases for cleanup does not worth the effort now. I agree.
However, it does for future. IMHO.
The problem is, that there is no neat dividing line between "short term" and "long term". One blurs into the other, and different people were perceive the pace of change differently. A long overlap with multiple names for everything has its costs, and a short overlap with lots of breaking changes also has its cost.
Note that the alternative I and others are advocating is not "no change", but "radical change" - rather than introducing different names for functions that work in exactly the same way, introduce new ways of achieving the same thing, with a nicely unified structure. This makes it a much easier to decide and announce "we're going to use OO-style strings" (or whatever scheme is invented).
Name collision by adding aliases is not much issue with namespace.
You keep bringing this up, but I for one have never mentioned it as an issue with adding aliases. My point is entirely about the value and cost of having multiple names with identical meaning.
I mentioned using namespaces (in the technical sense) as a way of radically rearranging functions (e.g. array\filter(), array\sort\callback\associative() but better thought out than that) but that's nothing to do with name collision really.
Anyone who don't care cleanup, they don't have to care and keep
using old names.
Don't forget that a language needs to be easy to *read* as well as easy to *write* - if one person ignores the new names, but then reads code using them, that code is harder for them to understand.
In short: there may be particular cases where the advantages of adding an alias outweigh the disadvantages, but it's by no means automatic, and doing it across the whole of PHP is not going to automatically be good for the language's future.
Regards,
--
Rowan Collins
[IMSoP]