Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73269
Return-Path: <me@rouvenwessling.de>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 42720 invoked from network); 18 Mar 2014 11:28:29 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 18 Mar 2014 11:28:29 -0000
Authentication-Results: pb1.pair.com smtp.mail=me@rouvenwessling.de; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=me@rouvenwessling.de; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain rouvenwessling.de designates 5.35.242.46 as permitted sender)
X-PHP-List-Original-Sender: me@rouvenwessling.de
X-Host-Fingerprint: 5.35.242.46 rouvenwessling.de Linux 2.6
Received: from [5.35.242.46] ([5.35.242.46:42795] helo=lvps5-35-242-46.dedicated.hosteurope.de)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id D1/C3-23742-DDD28235 for <internals@lists.php.net>; Tue, 18 Mar 2014 06:28:29 -0500
Received: by lvps5-35-242-46.dedicated.hosteurope.de (Postfix, from userid 5001)
	id AE2EB69F14F7; Tue, 18 Mar 2014 12:28:25 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	lvps5-35-242-46.dedicated.hosteurope.de
X-Spam-Level: 
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham version=3.3.1
Received: from [192.168.0.124] (ip-88-152-75-113.unitymediagroup.de [88.152.75.113])
	by lvps5-35-242-46.dedicated.hosteurope.de (Postfix) with ESMTPA id 0BF8569F03BF;
	Tue, 18 Mar 2014 12:28:25 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
In-Reply-To: <CAPwsocGpFwHkNjLG4m-u95rprHdVX2hVN+XYA9N8bUTDAMqZ9Q@mail.gmail.com>
Date: Tue, 18 Mar 2014 12:28:24 +0100
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>,
 "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: Leigh <leight@gmail.com>
X-Mailer: Apple Mail (2.1874)
Subject: Re: [PHP-DEV] Session: deprecating create_sid() method and add createSid()?
From: me@rouvenwessling.de (=?iso-8859-1?Q?Rouven_We=DFling?=)


On 18.03.2014, at 12:17, Leigh <leight@gmail.com> wrote:

> I might be missing something but I have to agree with
>=20
> On 18 March 2014 07:44, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>>=20
>> Doing to all this length for what? To rename a function? Looks hardly
>> worth it.
>=20
>=20
> The method is named as it is in userland because it maps 1:1 with the
> underlying interface
>=20
> open -> open
> destroy -> destroy
> create_sid -> create_sid
>=20
> Seems like a big waste of time, and hassle for people who use it, when =
you
> 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, since 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 high level language and should abstract =
these concerns away from users.

Best regards
Rouven=