Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84619
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5500F527.1030606@lsces.co.uk>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@mail.gmail.com>
 <54F83C4D.1020206@gmail.com> <CAEZPtU6ni038E+b0ziAC1b0w=t3gsmBwMjAui4e0sXd8EgbyXQ@mail.gmail.com>
 <CAL0xaBF7u2h9A5UnVB+-z6SwDtLOVY_qL7B9UGj7w_Lecwct6A@mail.gmail.com>
 <CAGa2bXa5zER03VrMrtD9aUQ38LK9C_UWU-jbGjzEZUoxbUsSQQ@mail.gmail.com>
 <54F8BF67.6080600@gmail.com> <CAGa2bXbvZbMb5C0RnaDAVTAMK_+9x-BzidXcm9MgoaGmtWK+Zg@mail.gmail.com>
 <848D3C19-DE29-4E5F-9B23-D87D3F4A9365@gmail.com> <CAGa2bXZgx4JCv3e5a94SXwYOnLMXjYcXdMizdQ9bpqZz7oYGzQ@mail.gmail.com>
 <54FB45D6.3040803@gmail.com> <CAGa2bXYU_DRuo3T8WRuq=3Xih79BZ7vHqYOnry2AvxgVx8g0WA@mail.gmail.com>
 <54FCD063.4040300@gmail.com> <CAGa2bXYt_zHfLgKEXP+uzTH0KbeAqRmxxEAcCtsMYgyW4ptfSA@mail.gmail.com>
 <54FEB910.5000608@lsces.co.uk> <CAGa2bXbLVoBM+d0VVqwm8-tKaFWRE1WpMnLMaFWVHMjH4hRvDA@mail.gmail.com>
 <54FF5E39.7000507@lsces.co.uk> <550035F0.10703@gmail.com> <CAGa2bXZ=ukPSLp3woZsuHo+s37VnV3XJ1izFvzRwnNjuARh+PA@mail.gmail.com>
 <5500F527.1030606@lsces.co.uk>
Date: Thu, 12 Mar 2015 11:21:13 +0200
Message-ID: <CAL0xaBHWVg8xsTyPygW4QF-3EVjpBNmGt4TORMaLtN1nAqK-uw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c17b98ef1cee051113e870
Subject: Re: [PHP-DEV] Consistent function names
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a11c17b98ef1cee051113e870
Content-Type: text/plain; charset=UTF-8

2015-03-12 4:08 GMT+02:00 Lester Caine <lester@lsces.co.uk>:

> On 11/03/15 22:44, Yasuo Ohgaki wrote:
> > Having namespace for internals would bring much flexibility for API
> changes, both
> > OO and procedural API. I may try my best to have consensus.
> >
> > I think you also like to have OO style API for basic
> > variables(int/float/array) as I am.
> > Unless we have good/proper procedural API names, it would be an obstacle
> to
> > have OO style API for basic variables. I wish you agree to do something
> for it.
>
> Personally I just want to keep the current name set and so the sheer
> volume of changes proposed is a big kick in the face to me. People are
> talking about the need for an OO based interface, but there has been no
> comment by anybody as to how that should be styled. Having switched
> everything to camelCase as part of the E_STRICT reworking that is
> already well established so while I can see why you want to complete a
> complete switch to underscore padded names THAT is not consistent with
> what everybody else is already using?
>
> There should not be two naming styles running in parallel and that is
> all I am objecting to. If you get support for this RFC then both an
> extended namespace name set and OO based objects should all follow the
> same rules, and THAT is not what has been happening?
>
> I think it is equally valid to ask if the current naming guide IS still
> appropriate or if a switch to camelCase for every name space is more
> practical moving forward. In which case dropping the extra underscores
> makes more sense than adding hundreds more! That a name can be written
> all lower case, all upper case or any combination is more a matter of
> choice, but as you say error messages adopt a standard that may not
> match what is in the code anyway?
>
> --
> Lester Caine - G8HFL
>

Basically this.

Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one now,
and adding a new subset of it looks pointless. It has it's problems and
legacy, you can't really fix it. Maybe some adjustments are in order to
make it more consistent where it can be done.

I really see only the OO API as a new additional interface. It's part
started by the DateTime, the MySQLi classes and stuff. At this point all
that stuff can be still namespaced, adjusted if needed and continued, just
from the std library first.
I, actually, use _ for function and variable naming and camelCase for
object methods and properties.  To be frank, I like it - it visually
clearly separates the code styles and for the most part the PHP code is
written that way (well, the MySQLi has ->num_rows and stuff - i'd change it
to ->numRows and so forth).

Arvids.

--001a11c17b98ef1cee051113e870--