Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71571
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52E40F7E.3050001@gmail.com>
References: <CAGa2bXZJoyV+9qN6v8j3+vHexoqDtHR4cZkgdtdc1GpVkDaD9w@mail.gmail.com>
 <CAGa2bXY4=3UVDVdR=curS96r=pvTrxDYA0wgy+k7X46omtTPgQ@mail.gmail.com>
 <7E.A3.39789.25841E25@pb1.pair.com> <CAGAGxbb5xTCQaS7=1BPN0pWPz_Z3MqegJkaJFZfg8Eou+zELYA@mail.gmail.com>
 <12.A5.39789.B7851E25@pb1.pair.com> <52E16E01.7070401@gmail.com>
 <52E1BDB0.6050406@garfieldtech.com> <CAGa2bXYUg_YfOhbOVJpt+Hr6R5H34wb1h6dzov-sAzxz-fJtEw@mail.gmail.com>
 <52E40F7E.3050001@gmail.com>
Date: Sun, 26 Jan 2014 08:36:32 +0900
Message-ID: <CAGa2bXaEnYfBkWXTMARg4h4+s5QDHMNPHLB9UT9CgNdwDu_-og@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c26230313d7d04f0d3f44d
Subject: Re: [PHP-DEV] Re: [PHP6] Function name consistency
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c26230313d7d04f0d3f44d
Content-Type: text/plain; charset=UTF-8

Hi Rowan,

On Sun, Jan 26, 2014 at 4:24 AM, Rowan Collins <rowan.collins@gmail.com>wrote:

> On 24/01/2014 20:27, Yasuo Ohgaki wrote:
>
>> Hi Larry,
>>
>> On Fri, Jan 24, 2014 at 10:11 AM, Larry Garfield <larry@garfieldtech.com
>> >wrote:
>>
>>  On 1/23/14 1:31 PM, Rowan Collins wrote:
>>>
>>>   Therein lies the whole problem with adding more aliases - it just makes
>>>
>>>> things more inconsistent, as developers can use (deliberately or
>>>> accidentally) different names for the same function.
>>>>
>>> Agreed.  Simply aliasing a bunch of functions offers no useful value, but
>>>
>>> does increase confusion.  ("Wait, do I use strcmp() or string_compare()
>>> on
>>> this project?  What version are we on again?  Oh, look, this library uses
>>> both.  Must have been different devs.  FML.")
>>>
>>> If we're going to do anything, be aggressive and far-reaching with it.
>>> Build a proper language-level OOP design for string/array manipulation.
>>>
>>> We have enough functions lying about.  Don't add more.
>>>
>>
>> We should be careful choosing names. I agree.
>> However, not adding more function names is simply impossible.
>>
>
> The discussion seems to have veered off on a tangent here - we were
> talking about adding *aliases* (new names for existing functions) that were
> more consistent/standardised, and why that can cause more harm than good.
>

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.


Adding new functions for new functionality is an entirely different
> discussion. In general, I do feel that piecemeal additions like
> array_column() have a rather marginal benefit, and it would be nice if more
> parts of the standard library used OOP or at least namespaces, but having a
> rich standard library of functions is definitely a good thing. The
> password_* functions, for instance, are an excellent thing to have
> standardised and ready "out of the box".
>
> But that's all completely beside the point in a discussion about giving
> existing functions new names.


My question is, are people willing to learn/keep using PHP 10 years later?
People don't choose languages by function names, but how they feel
would be important.

We might had pg_exec() and pg_execute() while most other database module
uses *_query() for executing SQL text directly. We may say it's been named
after PQexec, so there is pg_exec(), no pg_query() forever. It's
acceptable, but
it's not optimum.


Adding aliases for cleanup does not worth the effort now. I agree.
However, it does for future. IMHO.

Name collision by adding aliases is not much issue with namespace.
Anyone who don't care cleanup, they don't have to care and keep
using old names.

For example, pgsql module has many aliases. These are about 10 years old or
so
and these aliases will be in the module many more years.

    /* aliases for downwards compatibility */
    PHP_FALIAS(pg_exec,          pg_query,          arginfo_pg_query)
    PHP_FALIAS(pg_getlastoid,    pg_last_oid,       arginfo_pg_last_oid)
#if HAVE_PQCMDTUPLES
    PHP_FALIAS(pg_cmdtuples,     pg_affected_rows,
 arginfo_pg_affected_rows)
#endif
    PHP_FALIAS(pg_errormessage,  pg_last_error,     arginfo_pg_last_error)
    PHP_FALIAS(pg_numrows,       pg_num_rows,       arginfo_pg_num_rows)
    PHP_FALIAS(pg_numfields,     pg_num_fields,     arginfo_pg_num_fields)
    PHP_FALIAS(pg_fieldname,     pg_field_name,     arginfo_pg_field_name)
    PHP_FALIAS(pg_fieldsize,     pg_field_size,     arginfo_pg_field_size)
    PHP_FALIAS(pg_fieldtype,     pg_field_type,     arginfo_pg_field_type)
    PHP_FALIAS(pg_fieldnum,      pg_field_num,      arginfo_pg_field_num)
    PHP_FALIAS(pg_fieldprtlen,   pg_field_prtlen,   arginfo_pg_field_prtlen)
    PHP_FALIAS(pg_fieldisnull,   pg_field_is_null,
 arginfo_pg_field_is_null)
    PHP_FALIAS(pg_freeresult,    pg_free_result,    arginfo_pg_free_result)
    PHP_FALIAS(pg_result,        pg_fetch_result,   arginfo_pg_get_result)
    PHP_FALIAS(pg_loreadall,     pg_lo_read_all,    arginfo_pg_lo_read_all)
    PHP_FALIAS(pg_locreate,      pg_lo_create,      arginfo_pg_lo_create)
    PHP_FALIAS(pg_lounlink,      pg_lo_unlink,      arginfo_pg_lo_unlink)
    PHP_FALIAS(pg_loopen,        pg_lo_open,        arginfo_pg_lo_open)
    PHP_FALIAS(pg_loclose,       pg_lo_close,       arginfo_pg_lo_close)
    PHP_FALIAS(pg_loread,        pg_lo_read,        arginfo_pg_lo_read)
    PHP_FALIAS(pg_lowrite,       pg_lo_write,       arginfo_pg_lo_write)
    PHP_FALIAS(pg_loimport,      pg_lo_import,      arginfo_pg_lo_import)
    PHP_FALIAS(pg_loexport,      pg_lo_export,      arginfo_pg_lo_export)
#if HAVE_PQCLIENTENCODING
    PHP_FALIAS(pg_clientencoding,       pg_client_encoding,
arginfo_pg_client_encoding)
    PHP_FALIAS(pg_setclientencoding,    pg_set_client_encoding,
arginfo_pg_set_client_encoding)

I suppose most pgsql users are pleased these new names and aliases.

It would be nice to do the same for other functions. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c26230313d7d04f0d3f44d--