Re: [PATCH] session_set_save_handler(class)

On Wed, Dec 9, 2009 at 2:35 AM, Stanislav Malyshev <stas@zend.com> wrote: > Hi! > > > By extending the new internal class SessionHandler, users can wrap or >> override methods of whatever session handler is in use, or implement a >> complete custom handler. >> > > Hi, Thanks very much for your feedback, I've made some changes in the attached patch. > Couple of notes: > > 1. I'd call mod_active something more clean - like session_active? > This flag indicates whether the mod should be called from the usual session events. There might be a better name for it but there's already a session_active with a different meaning. > 2. What happens if session module is set to "user" in configuration - what > old_mod will be then and how this patch will work? > It now raises an error rather than segfaulting if the user module is selected but no handler has been registered. This should really halt execution which it doesn't at the moment but I'll raise that separately. old_mod is only set in the first call to session_set_save_handler(), so subsequent calls just replace each other. Inheritance can be achieved by extending the previous class or calling the previous functions from the new class. 3. old_mod is also not a clear name - maybe default_mod? > Ok, changed. > 4. I think it also makes sense to allow passing object instead of class. > I've allowed objects to be passed now but I think this should probably be discouraged since it's going to be called in a static context anyway. > 5. In fact, thinking about it - maybe it should be an interface and not a > class? > I made it a class rather than an interface to allow easy inheritance of the default handler. This way it's always parent::foo() whether extending directly from SessionHandler or a child class. It also means users only need to implement the methods they actually use. Regards, Arpad

Attachment: [text/x-diff] php6-session-oo-01.patch