Re: Headsup: PHP7 feature freeze

Hi Anatol, On Mon, Jun 29, 2015 at 10:19 PM, Anatol Belski <anatol.php@belski.net> wrote: > > -----Original Message----- > > From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo > > Ohgaki > > Sent: Friday, June 26, 2015 1:58 PM > > To: Hannes Magnusson > > Cc: Kalle Sommer Nielsen; Internals; Anatoliy Belsky; Dmitry Stogov; > Nikita > > Popov; Ferenc Kovacs; Xinchen Hui > > Subject: Re: [PHP-DEV] Headsup: PHP7 feature freeze > > > > Hi all, > > > > On Fri, Jun 26, 2015 at 12:56 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> > wrote: > > > > > Hi Hannes, > > > > > > On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> > wrote: > > > > > >> On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson < > > >> hannes.magnusson@gmail.com> wrote: > > >> > > >>> Why do you think its undocumented? > > >>> http://php.net/manual/en/sessionhandler.create-sid.php� > > >>> ������B��J�g > > >>> > > >> > > >> Rename discussion was there. And I explicitly discussed "it's > > >> undocumented and it violates CODING_STANDARDS", but it was added > > >> recently (after the discussion I suppose). > > >> > > >> [yohgaki@dev session]$ svn log -r 334814 > > >> --------------------------------------------------------------------- > > >> --- > > >> r334814 | aharvey | 2014-09-09 04:49:26 +0900 (2014年09月09日 (火)) | 2 > > >> lines > > >> > > >> Add documentation for SessionHandler::create_sid(). > > >> > > >> --------------------------------------------------------------------- > > >> --- > > >> > > >> 334814 aharvey <classname>SessionHandler</classname> is a > special > > >> class that can be used > > >> 334814 aharvey to expose the current internal PHP session save > > >> handler by inheritance. > > >> 334814 aharvey There are seven methods which wrap the seven > > >> internal session save handler > > >> 334814 aharvey callbacks (<parameter>open</parameter>, > > >> <parameter>close</parameter>, > > >> 334814 aharvey <parameter>read</parameter>, > > >> <parameter>write</parameter>, > > >> 334814 aharvey <parameter>destroy</parameter>, > > >> <parameter>gc</parameter> and > > >> 334814 aharvey <parameter>create_sid</parameter>). By > > >> default, > > >> this class will wrap > > >> 334814 aharvey whatever internal save handler is set as > defined by > > >> the > > >> 334814 aharvey <link > > >> linkend="ini.session.save-handler">session.save_handler</link> > > >> 334814 aharvey configuration directive which is usually > > >> <parameter>files</parameter> by > > >> 334814 aharvey default. Other internal session save handlers > are > > >> provided by PHP > > >> 334814 aharvey extensions such as SQLite (as > > >> <parameter>sqlite</parameter>), Memcache (as > > >> 334814 aharvey <parameter>memcache</parameter>), and Memcached > > (as > > >> 334814 aharvey <parameter>memcached</parameter>). > > >> > > >> I think this should be reverted. > > >> > > > > > > Or it may stay there. > > > It's just a matter of having a copy of create_sid(). > > > I'll add documentation. > > > > > > > I forgot that session_create_id() is needed createSid() method to be more > > useful. > > > > The code for session_create_id() is in the source, but it isn't enabled.. > > I wouldn't like to have different naming session_create_id() and > createSid(). > > > > So I would like to have > > - session_create_id() function > > - createId() function > > because there is > > - session_id() > > since PHP4. > > > > I don't think session internal names do not have to be changed. > > i.e. Macros, etc. > > Any comments? > > > Changing internal or user space API is kind of too late, IMHO. Especially > the user space APIs that are documented. But also the internals, as a lot > of extensions are already ported. Also because sessions are a core > functionality where changes should be supported but a good migration path.. > Please target later 7.x versions with this change. But probably would make > sense to create an RFC and start the discussion like already... yesterday, > so the topic is good discussed and accepted for the next. No problem. I'll write a RFC for this. For the record, please don't document questionable APIs... I'll add comment to source if there are similar cases. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net