Hi Anatol,

On Mon, Jun 29, 2015 at 10:19 PM, Anatol Belski <anatol....@belski.net>
wrote:

> > -----Original Message-----
> > From: yohg...@gmail.com [mailto:yohg...@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 <yohg...@ohgaki.net>
> wrote:
> >
> > > Hi Hannes,
> > >
> > > On Fri, Jun 26, 2015 at 12:51 PM, Yasuo Ohgaki <yohg...@ohgaki.net>
> wrote:
> > >
> > >> On Fri, Jun 26, 2015 at 10:48 AM, Hannes Magnusson <
> > >> hannes.magnus...@gmail.com> wrote:
> > >>
> > >>> Why do you think its undocumented?
> > >>> http://php.net/manual/en/sessionhandler.create-sid.php
> > >>>
> > >>
> > >> 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
yohg...@ohgaki.net

Reply via email to