Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84287
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_470E36BA-3884-49F7-8C96-3EEA821F7BFD"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <54F6C936.9080406@lsces.co.uk>
Date: Wed, 4 Mar 2015 11:16:55 +0100
Cc: internals@lists.php.net
Message-ID: <6242A102-28DB-42F7-A99C-3C08C5020799@php.net>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@mail.gmail.com> <CAEZPtU6=KY2tzRE8yw6kEdh4SrVJ3uG81XX5yuu0E_63G1HN6g@mail.gmail.com> <54F4E29D.7080501@garfieldtech.com> <CAGa2bXbph51CUHr_G87FL65hSDfLSDHo14Bnke-vaLu7SmH=ZQ@mail.gmail.com> <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com> <CAGa2bXaQ0SgLWdv7WCoo_qyOQH=t2Vi_bwpk7qXZDEUk+7S7ew@mail.gmail.com> <54F4F3FC.6060501@fischer.name> <CAGa2bXb-d7A3So8e76=p5qqxrZgLK2B_4RKA1OKg0nHZiw9z6A@mail.gmail.com> <54F4FDFB.8010701@lsces.co.uk> <CAGa2bXZUvJJVDVj-48qpPuMas12fnDigKGcE-r=TK20Sahyi7w@mail.gmail.com> <54F5895D.3090002@gmail.com> <CAGa2bXbuNEcvoeeBhkUUEkiHZJFvJTVX=h_JPTLHpMTtgbCokw@mail.gmail.com> <554F0C3F-770F-4694-A5AB-FDC54FCCBF00@gmail.com> <CAGa2bXbDdS=N=JmPwBa1iorx1aJPuo00EfU7bw31cknAxAfDyQ@mail.gmail.com> <CAEu+QUX1j2P+OfU+Sf_wUOQzYrLody0zPF6V9rVWvYjGFfbrSg@mail.gmail.com> <CAGa2bXZYG37qdkjTkoDq12GtYTwS-=gX-=msPx3RWeSenxSdqw@mail.gmail.com> <54F6C936.9080406@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>
Subject: Re: [PHP-DEV] Consistent function names
From: mike@php.net (Michael Wallner)

--Apple-Mail=_470E36BA-3884-49F7-8C96-3EEA821F7BFD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 04 03 2015, at 09:58, Lester Caine <lester@lsces.co.uk> wrote:
>=20
> On 04/03/15 03:34, Yasuo Ohgaki wrote:
>> I made list of rename candidates
>> =
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be=
_renamed
>> If you have suggestions, I appreciate!
>=20
> Taking the starting point ... the coding standard for writing C code =
for
> PHP ... personally I would love if the PHP code area followed all of =
the
> rules in the C set. My own particular grip is with using tabs =
internally
> in the C code, but spaces in the PHP code. The very reason that PSR is
> another inconsistency. So we follow C rules for C code and PSR rules =
for
> PHP. Or not ... I will always use tabs across all code bases, but the
> other point here is that PSR demands camelCase rather than adding
> underscores and many of the new libraries have been added following =
that
> format rather than the C rules.
>=20
> So even replacing the whole structure of internal names, they will be
> inconsistent with external naming 'rules'. The coding standards
> themselves are inconsistent :(
>=20
> If we are looking at the C codespace, then as has already been said we
> are using C library names in a large majority of cases. So programmers
> who are switching between C and PHP codespace either need to rebuild =
all
> of the C libraries using the new names, or live with that =
inconsistency?
>=20
> I am slowly coming around to the thought that since how I would prefer
> to work is not going to be provided by PHP then creating my own =
versions
> of some extensions is going to be the right way forward, so I will
> perhaps be working more in 'C' space than in 'PHP' space. This is =
partly
> because of the growing uncertainty about handling SQL compliant types =
in
> PHP, and the increasing need to work out how to add back the limit
> checks provided naturally by 32bit processor builds. There are a lot
> more important things than introducing what I view as yet another =
layer
> of inconsistency when for example, the whole string management area
> needs to be augmented with a proper object based structure where the
> str_ becomes redundant? mbstring should also become redundant in that
> rework.
>=20
> As I have already said, the GD library is just a wrapper around the
> underlying libgd C package, and while it is now maintained by Pierre
> under the umbrella of PHP, it is used in other languages so creating a
> new wrapper for PHP without regard for it's C and other interfaces is
> again introducing more inconsistencies.
>=20
> While http has been rejected for bundling, it is another example of =
not
> following the C coding standard =E2=80=A6

Lester, please stop posting walls of unrelated text. You=E2=80=99re =
totally off track. If we=E2=80=99re talking about coding standards, =
we=E2=80=99re not talking about PSR, but =
http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS =
<http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS>

Regards,
Mike


--Apple-Mail=_470E36BA-3884-49F7-8C96-3EEA821F7BFD--