Hi,
On Sat, Jan 24, 2015 at 2:24 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi Stas, > > On Sat, Jan 24, 2015 at 8:49 AM, Stanislav Malyshev <smalys...@gmail.com> > wrote: > >> > This is the only reasonable use I know. I would to write user >> > serializer(read/writer) >> > handler for it. >> >> So we went from no reasonable use to one reasonable use, documented at >> the manual. I think it is also reasonable to suppose there are more uses >> for it. >> > > This is because session module lacks user defined serializer. Save handler > handles session data storage. Serialize handler handles how data is > converted/represented. IMHO. > That's not the only use case. Some time ago I proposed a session.match_ip feature and argued that if I wanted to implement it in userland code, I'd have to implement the *whole* session handler from scratch. An example using the SessionHandler class proved me wrong in that regard. Surely, people are using it for other stuff as well and it's not about the serializer. > I would like to make SessionHandler deprecated, encourage user serialize > handler for new PHP because it's more efficient and clean. Do you agree? > How can it possibly be more efficient and clean if you have to re-implement everything with user-level code? > Let's keep SessionHandler class. However, > PHP_FUNCTION(session_set_save_handler) > should be cleaned up to verify implemented/extended interface/class. It's > BC. > Do you have opinion for this? php > session_set_save_handler(new stdclass); PHP Warning: session_set_save_handler() expects parameter 1 to be SessionHandlerInterface, object given in php shell code on line 1 Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
