Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.48 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54FAD3D5.2030509@lsces.co.uk>
References: <CAGa2bXai0cXrqeq3X2vTV8CjseAp=CUY29YaaxKniZENw0-x4g@mail.gmail.com>
 <op.xuxm3hojhuszwh@tsukapiou> <CAGa2bXbiQw82=+cGPurRwTnsD31MaZ9mM_e3WWLNPgcNz+H5zg@mail.gmail.com>
 <CANUQDCh4VGqHLuixRAHn42dGJ52yuhbkV-4_JyBntqsDgmm6Cg@mail.gmail.com>
 <CAGa2bXbVaFdqi-f-T8Ar4RvXrEipbCb1NvJGRKC+bieFndGueQ@mail.gmail.com>
 <726CA870-917C-4270-A129-AFE106E0A380@gmail.com> <54F84208.4020709@lsces.co.uk>
 <CAGa2bXZZ31_VXKCLU-O66FYWOo=2PR0A3ma-YOm+BkrREdMdZw@mail.gmail.com> <54FAD3D5.2030509@lsces.co.uk>
Date: Sun, 8 Mar 2015 07:35:56 +0900
Message-ID: <CAGa2bXauR1H0BoGfdkeyvMJ8=4qSF9L9eC-HBf-YaSV-+6Th1w@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01182b761f5d8b0510ba6f0c
Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] Consistent Function Names
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e01182b761f5d8b0510ba6f0c
Content-Type: text/plain; charset=UTF-8

Hi all,

On Sat, Mar 7, 2015 at 7:32 PM, Lester Caine <lester@lsces.co.uk> wrote:

> On 06/03/15 23:18, Yasuo Ohgaki wrote:
> > Hi Lester,
> >
> > On Thu, Mar 5, 2015 at 8:46 PM, Lester Caine <lester@lsces.co.uk> wrote:
> >
> >> On 05/03/15 09:40, Rowan Collins wrote:
> >>>>>
> >>>>> Good point!
> >>>>> I'll update documents so that main function is prefered name/function
> >>>>> to be
> >>>>> used.
> >>> This would be fine if all the users read the manual, and only the
> >> manual. What about the thousands of books, tutorials, blog posts, Stack
> >> Overflow q&as, etc, all mentioning the names and behaviour that have
> been
> >> around for 15 to 20 years? Not to mention the thousands of lines of
> >> existing code which people will not only need to read and understand,
> but
> >> also contribute to without accidentally breaking compatibility with old
> >> versions of PHP.
> >> This is perhaps the key ...
> >>
> >> Yasuo has at least now come on board over the IEEE standards but has
> >> also spotted that because of allowing a little to much freedom in the
> >> past some of the current guide lines do not marry with the well
> >> established standards :(
> > I've updated the RFC to have IEEE names as well as other established
> > library function
> > names as valid names. We wouldn't have much problem having aliases for
> it.
> > I think it would be useful.
>
> One of my own personal gripes has always been that while some names are
> consistent with the standard, the rules for adding names adopted at the
> time wasn't? It is this which has created the problem and if there is
> any reason to change things now it should be to follow the IEEE coding
> style which is also followed by secondary libraries like gettext.
>
> is_int should simply be isint in line with the IEEE standard but that
> divergence of standards was not a good enough reason to avoid the
> current 'inconsistencies' at the time?
>

I don't know how CONDING_STARNDARDS is made. Anyone remember
the discussion?

PHP has function names copied from C libraries at the beginning. Then
name with "_" became standard. Therefore, we have phpversion(), isset().
I remember empty() discussion whether it should be is_empty() or empty().
Shorter name is preferred and empty() is used. We chose
inconsistent names on occasions like StdClass::__set_state().

Having C library like name is not bad, but I think too many aliases are
better
to be avoided. Especially for basic functions. I'm not sure if it's good
for PHP
to have isstring(), isarray(), etc. It's one possibility though.


>
> > The bit I'm still unsure of here is not so much messing with some of the
> >> fine detail of the procedural based functions, but the coding standard
> >> that ACTUALLY applies at the object level. Using one naming standard for
> >> ths area and a different one for an object version of the same set of
> >> functions is equally confusing?
> >
> > I agree. I wouldn't rush into.
> > If we change, we should change them right.
> >
> > We have the implementation already.
> > http://php.net/arrayobject
> >
> > I looked into the implementation. I'm surprised that it's overly
> > complicated.
> > It uses "array(hash)" and "object" for array storage for some reasons.
> This
> > makes it difficult to reuse procedural implementation. We may do
> something
> > for this issue.
>
> One of the reasons I don't think it as caught on?
> But the starting point here is naming methods in these objects and the
> 'assumed standard' seems to be camelCaseStyle rather than under_style ?
> Again the horse has bolted since objects like http are now well
> established with camelCaseStyle rather than following the C coding style
> anyway.
>
> The only question that needs answering first is just what standard ARE
> we working to and what should that be to be consistent between
> procedural and object models?


Function names without "_" is better for camelCase methods. I agree.
Personally, I don't have any bad impression for having "_" for procedural
functions while having camelCase for methods.

It's valid option to have camelCase for procedural functions' main name.
I don't mind removing "_" from procedural functions much, but C library
names are not standardized well enough. (I mean naming convention
differs library to library) My current impression is having "_" in names
and have PHP name would seem more consistent.

I guess this is the reason why CODING_STANDARDS is made like it
is now. We may introduce new procedural naming standard with
camelCase name that can keep consistency.

Thoughts?


Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e01182b761f5d8b0510ba6f0c--