Hi Rowan,
On Mon, Jan 27, 2014 at 3:38 AM, Rowan Collins <[email protected]>wrote:
> 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.
>>
>
> It's certainly true that aliases are not automatically a bad idea. There
> might have been a bit of confusion when it was introduced and people
> thought the functions did different things, but in this case, the old
> function probably wasn't something people typed on a day-to-day basis.
I guess many users don't type native module function names now a days,
since most users are using some kind of framework.
>
> 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 would be typed by many users.
> 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.
I understand this argument. Since we have short release cycle and rather
short life for a release, this is short term disadvantage. They may keep
using aliases functions also.
> 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.
>
Keeping inconsistent names have its cost also.
> 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).
It's nice to have them.
Even when we have nice OO style API, old functions will remain forever,
probably.
>
> 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.
>
Good!
I realize cost of having aliases also.
The only difference here is you think cost of alias outweigh while I think
cost of inconsistent names outweigh.
> 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.
>
IMHO, aliases would not affect readability. Users would understand what
word_wrap() and wordwrap()
htmlspecialchar and html_special_chars()
and so on
means.
I still check correct name see if it has "_" delimited name or not for
rarely used functions.
(I don't use IDE to write PHP code ;)
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.
I agree that automatic aliasing would not be good.
String and array function names needs more discussion.
GD function names may be aliased automatically, for example.
We should discuses if we are going to add standard name aliases
to module functions or not, perhaps?
Regards,
--
Yasuo Ohgaki
[email protected]