Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70952
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZJoyV+9qN6v8j3+vHexoqDtHR4cZkgdtdc1GpVkDaD9w@mail.gmail.com>
References: <CAGa2bXZJoyV+9qN6v8j3+vHexoqDtHR4cZkgdtdc1GpVkDaD9w@mail.gmail.com>
Date: Thu, 2 Jan 2014 09:07:31 +0100
Message-ID: <CAEZPtU4bMfnQOCUr5DyGTpoysDpuZFKnCrymu0XvPgCj2CWQMQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0158b5bc04328d04eef84978
Subject: Re: [PHP-DEV] [PHP6] Function name consistency
From: pierre.php@gmail.com (Pierre Joye)

--089e0158b5bc04328d04eef84978
Content-Type: text/plain; charset=UTF-8

On Dec 28, 2013 1:58 PM, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:
>
> Hi all,
>
> I know this has been discussed before, but I'll try again.
> We have following coding standard
>
> 1.  Function names for user-level functions should be enclosed with in
>     the PHP_FUNCTION() macro. They should be in lowercase, with words
>     underscore delimited, with care taken to minimize the letter count.
>     Abbreviations should not be used when they greatly decrease the
>     readability of the function name itself::

There are a couple of solutions to this problem.

1. Change all the existing functions signatures. Bad idea per se as we can
forget any fast adoption, if any at all. Will be very painful to migrate
existing code

2. Add aliases all around.
    Not a big fan of that one either. It clutters the php NS a lot without
factual gains

3. Try to implement nickic's prototype to add methods to scalar related
types, should work with complex types as well

I would prefer to give 3. a try, while it could be tricky to implement a
technically acceptable solution.

Pros:

. It will bring consistent APIs
. does not add dozen of aliases for little gains
. fully BC
. fits more to current development habits

Cons:
. still have to be careful by designing the new "methods"

Cheers,
Pierre

--089e0158b5bc04328d04eef84978--