Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73273
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <772CEF30-7D4B-4E68-A698-6EBAFA896777@rouvenwessling.de>
References: <CAGa2bXb09KO-ydd-vf3rJMR=pjQZ=1kG0Qq+snLoKPEL+Fp6XQ@mail.gmail.com>
	<CAGa2bXZGK06+aqe3HOEo9BC2R71a8HaBCqjBn=g_RbEK6u-Uqw@mail.gmail.com>
	<53277BE2.8020203@sugarcrm.com>
	<CAGa2bXadowN=wdxizXXLgOEB5pZArdAOEs653U-=5AkAcg6_4Q@mail.gmail.com>
	<5327F947.5020308@sugarcrm.com>
	<CAPwsocGpFwHkNjLG4m-u95rprHdVX2hVN+XYA9N8bUTDAMqZ9Q@mail.gmail.com>
	<772CEF30-7D4B-4E68-A698-6EBAFA896777@rouvenwessling.de>
Date: Tue, 18 Mar 2014 17:55:27 +0200
Message-ID: <CAPhkiZx3cq6t72Sfw3cK0cz9AucMA2JTQ-w677jC_CxYRiOgZg@mail.gmail.com>
To: =?UTF-8?Q?Rouven_We=C3=9Fling?= <me@rouvenwessling.de>
Cc: Leigh <leight@gmail.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Session: deprecating create_sid() method and add createSid()?
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, Mar 18, 2014 at 1:28 PM, Rouven We=C3=9Fling <me@rouvenwessling.de>=
 wrote:
>
> On 18.03.2014, at 12:17, Leigh <leight@gmail.com> wrote:
>
>> I might be missing something but I have to agree with
>>
>> On 18 March 2014 07:44, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>>>
>>> Doing to all this length for what? To rename a function? Looks hardly
>>> worth it.
>>
>>
>> The method is named as it is in userland because it maps 1:1 with the
>> underlying interface
>>
>> open -> open
>> destroy -> destroy
>> create_sid -> create_sid
>>
>> Seems like a big waste of time, and hassle for people who use it, when y=
ou
>> go around renaming things for the sake of it. Especially when that's all=
 it
>> is, a rename, no extra functionality.
>
> I agree, that's hardly worth it. I guess part of the problem in this case=
 was that it never went trough an RFC (At least I didn't know about it, sin=
ce it was never documented I think it's hardly known at all). What would be=
 great if we could get some clear cut naming conventions for user land APIs=
 otherwise we will keep making the API more inconsistent. The fact, that it=
 is mirroring the internal interface is a really bad argument. PHP is a hig=
h level language and should abstract these concerns away from users.

Couldn't have said it better.
Most OO APIs use camelCase, so I guess this was why Yasuo assumed it
and proposed this change. I think we should stick to that ... only
mysqli comes to mind that uses snake_names and that's probably because
it tries to mirror procedural functions.

Cheers,
Andrey.