Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73265
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.213.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5327F947.5020308@sugarcrm.com>
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>
Date: Tue, 18 Mar 2014 12:41:43 +0200
Message-ID: <CAPhkiZx_GSrLDZCSiW6N5YYugrKP4zpt1muU8LCpxKCrpUmK+A@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: Session: deprecating create_sid() method and add createSid()?
From: narf@devilix.net (Andrey Andreev)

Hey,

On Tue, Mar 18, 2014 at 9:44 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> If user uses undocumented interface (SessionIdInterface) they would have to
>> implement both createSid() and create_sid(). Alternatively, we may introduce
>> temporary interface for create_sid(). Or keep it undocumented and rename it
>> in 5.6 only.
>
> Doing to all this length for what? To rename a function? Looks hardly
> worth it.
>
>> Fortunately, current manual
>> http://jp2.php.net/manual/en/function.session-set-save-handler.php
>> is incomplete. It does not mention create_sid() and it's interface. It
>> does not
>> use interface for detailed version of example, too.
>
> It doesn't matter - it's there for 10 releases, so it's part of the API.
>
>> What is your opinion?
>
> My opinion it would be the best if we could support both and deprecate
> create_sid in 5.6, but if it's hard to do cleanly, then leave it alone.

I completely agree, and I think we're overthinking the possible
solution, so here's what I'm proposing:

Add SessionHandler::createId() to 5.5.next, when a userland session
handler is in use, it should look for createId() first, create_sid()
second and fallback to the internal implementation, whatever it is.
parent::create_sid() should call SessionHandler::createId() (this is
the dirty hack). Deprecate 'create_sid()' usage in 5.6.

Multiple arguments usage of session_set_save_handler() is not
affected, it only cares that you pass callables to it. Btw, this usage
should probably be deprecated as well, but that's the subject of a
separate discussion.

Cheers,
Andrey.