Hi all,
Object interface of session save handler has create_sid() method.
The name should createSid().
Renaming is BC, but createSid() could be added and make session
module to use createSid() when both exists. create_sid() may be
removed in future release.
Since many users would implement update() method and start defining
create_sid() method, it would be preferred to add createSid() in PHP 5.6
to prevent more mess.
I would like to
- Add
E_DEPRECATEDfor create_sid() - Add createSid()
- If both exists, use createSid()
- Remove create_sid() in future release. (PHP6?)
There is other option.
Since create_sid() method is undocumented, we may remove it, add
createSid() and add UPGRADING note for users using it currently.
http://jp2.php.net/manual/en/function.session-set-save-handler.php
Any comments?
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
Since create_sid() method is added in 5.5.1 and it's not documented yet.
I would like to propose renaming it to createSid() for both 5.5 and 5.6.
Any comments?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
Hi all,
Since create_sid() method is added in 5.5.1 and it's not documented yet.
I would like to propose renaming it to createSid() for both 5.5 and 5.6.Any comments?
I also thought about this, but I'm kind of split ... some users
(besides Leigh here) might've found it and be currently using it
regardless. And now that I know create_sid() exists, I'll surely use
it too in pre-5.6 apps. I guess it won't hurt to still look for it if
createSid() (or maybe even createId(), it's in the context of sessions
after all) doesn't exist.
Cheers,
Andrey.
Hi Stas,
Hi all,
Since create_sid() method is added in 5.5.1 and it's not documented yet.
I would like to propose renaming it to createSid() for both 5.5 and 5.6.Any comments?
I also thought about this, but I'm kind of split ... some users
(besides Leigh here) might've found it and be currently using it
regardless. And now that I know create_sid() exists, I'll surely use
it too in pre-5.6 apps. I guess it won't hurt to still look for it if
createSid() (or maybe even createId(), it's in the context of sessions
after all) doesn't exist.
What do you think about this?
It could be made both create_sid() and createSid() available in 5.5 and
remove create_sid() in 5.6.
Simple renaming is cleaner and may be acceptable, since it's undocumented
and relatively new feature. I'm not sure if it is good to have more complex
code
for undocumented feature.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Since create_sid() method is added in 5.5.1 and it's not documented yet.
I would like to propose renaming it to createSid() for both 5.5 and 5.6.
Renaming is a BC break and it's there for 10 releases already, so it'd
be a no go. You can add an alias of createSid, but then you'd have to be
very careful so that overriding both create_sid and createSid would work
the same (including when parent:: is involved). If it's hard to do
cleanly then I'd rather prefer keeping create_sid.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi Stas,
On Tue, Mar 18, 2014 at 7:49 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Since create_sid() method is added in 5.5.1 and it's not documented yet.
I would like to propose renaming it to createSid() for both 5.5 and 5.6.Renaming is a BC break and it's there for 10 releases already, so it'd
be a no go. You can add an alias of createSid, but then you'd have to be
very careful so that overriding both create_sid and createSid would work
the same (including when parent:: is involved). If it's hard to do
cleanly then I'd rather prefer keeping create_sid.
Since session module's object save handler support is legacy, session
module can modify how methods are used/defined when user is not using
interface.
i.e. session module is not using 'interface' normal way.
Procedural session_create_sid() API is there very long time, but
object's create_sid() method was introduced since 5.5.1. I would not
change procedural session_create_sid() name as it is proper name for it.
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.
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.
I'll update the manual when everything is sorted out.
For now, we should decide
- Keep create_sid() method in 5.5 or not
- Add createSid() method in 5.5 or not
- For interface, we have many options. Add new interface for createSid(),
simply adding createSid() to SessionIdInterface, etc.
I think session_sid() should be renamed to sessionSid() for 5.6, but I don't
care much about 5.5. I'll implement it in the way everyone satisfies.
What is your opinion?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
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.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hey,
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.
I might be missing something but I have to agree with
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 you
go around renaming things for the sake of it. Especially when that's all it
is, a rename, no extra functionality.
I might be missing something but I have to agree with
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 interfaceopen -> open
destroy -> destroy
create_sid -> create_sidSeems 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
Hi,
I might be missing something but I have to agree with
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 interfaceopen -> open
destroy -> destroy
create_sid -> create_sidSeems 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.
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.
Hi Stas,
On Tue, Mar 18, 2014 at 4:44 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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've included createSid() definition in
https://github.com/php/php-src/pull/628/
If create_sid() is defined, it's used. If both create_sid() and createSid()
is defined, createSid()
is used.
SessionHandler does not use new SessionUpdateTimestampHandlerInterface, so
user may
choose what they would do about create_sid() and createSid(). Current
session module's
object handling is some what legacy, so such thing can be done.
I think this is the best way. We can keep compatibility and have standard
confirming createSid()
name. Since it keeps compatibility with 5.5, we may leave 5.5 alone. If you
would like, I can
add similar change to 5.5.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
SessionHandler does not use new SessionUpdateTimestampHandlerInterface, so
Um ... what's the point of having this interface? Nothing uses it.
Cheers,
Andrey.
Hi Andrey,
SessionHandler does not use new SessionUpdateTimestampHandlerInterface,
soUm ... what's the point of having this interface? Nothing uses it.
You may use it like
class MySessionHandler implements SessionHandlerInterface,
SessionUpdateTimestampHandlerInterface
I think the name is too long.
Any suggestion?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
SessionHandler does not use new SessionUpdateTimestampHandlerInterface,
soUm ... what's the point of having this interface? Nothing uses it.
You may use it like
class MySessionHandler implements SessionHandlerInterface,
SessionUpdateTimestampHandlerInterfaceI think the name is too long.
Any suggestion?
It is too long, and also useless. :)
You may, or you may not call it. If it's not enforced anywhere, nobody
needs it and nobody is going to use it. I suggest removing it, it's
pointless.
Cheers,
Andrey.
Hi Andrey,
SessionHandler does not use new
SessionUpdateTimestampHandlerInterface,
soUm ... what's the point of having this interface? Nothing uses it.
You may use it like
class MySessionHandler implements SessionHandlerInterface,
SessionUpdateTimestampHandlerInterfaceI think the name is too long.
Any suggestion?It is too long, and also useless. :)
You may, or you may not call it. If it's not enforced anywhere, nobody
needs it and nobody is going to use it. I suggest removing it, it's
pointless.
It's intended for user use.
This is the normal use of interface.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
Hi Andrey,
SessionHandler does not use new
SessionUpdateTimestampHandlerInterface,
soUm ... what's the point of having this interface? Nothing uses it.
You may use it like
class MySessionHandler implements SessionHandlerInterface,
SessionUpdateTimestampHandlerInterfaceI think the name is too long.
Any suggestion?It is too long, and also useless. :)
You may, or you may not call it. If it's not enforced anywhere, nobody
needs it and nobody is going to use it. I suggest removing it, it's
pointless.It's intended for user use.
This is the normal use of interface.
Eh ... I know how an interface is used, but an interface is supposed
to enforce a certain set of methods to be implemented.
If you're not enforcing usage of the interface itself (which we can't
do, because of BC), it becomes optional and therefore enfoces nothing.
Cheers,
Andrey.
Hi Andrey,
Hi,
Hi Andrey,
On Wed, Mar 19, 2014 at 10:26 AM, Andrey Andreev narf@devilix.net
wrote:On Wed, Mar 19, 2014 at 3:22 AM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:SessionHandler does not use new
SessionUpdateTimestampHandlerInterface,
soUm ... what's the point of having this interface? Nothing uses it.
You may use it like
class MySessionHandler implements SessionHandlerInterface,
SessionUpdateTimestampHandlerInterfaceI think the name is too long.
Any suggestion?It is too long, and also useless. :)
You may, or you may not call it. If it's not enforced anywhere, nobody
needs it and nobody is going to use it. I suggest removing it, it's
pointless.It's intended for user use.
This is the normal use of interface.Eh ... I know how an interface is used, but an interface is supposed
to enforce a certain set of methods to be implemented.
If you're not enforcing usage of the interface itself (which we can't
do, because of BC), it becomes optional and therefore enfoces nothing.
I can enforce users to implement all of
SessionUpdateTimestampHandlerInterface when it is used.
I cannot enforce users to implement SessionIdInterface for
histrical/compatibility reason, though.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net