Re: Removing base class from session handler

Hi Stas, On Fri, Jan 23, 2015 at 3:47 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote: > > User may extend SessionHandler class like > > > > class MySession extends SessionHandler {} > > > > but user cannot extend base class(SessionHandler) capability because > > user script > > cannot access to PS(mod_data). > > Not sure what you mean by that. Absence of access to PS(mod_data) > certainly doesn't mean the user can not extend it's function, e.g. the > manual demonstrates EncryptedSessionHandler - is there something wrong > with that? Of course, there can be many more examples of it. > This is the only reasonable use I know. I would to write user serializer(read/writer) handler for it. User serializer is much powerful. Users may implement JSON/BSON/YAML/XML/ whatever serialization methods, along with encrypt/decrypt, compress/uncompress session data. NOTE: Session module always serialize session data with serializer, user cannot implement JSON/BSON/etc without native serializer. My point is SessionHandler class is (almost) useless as a CLASS. It requires implementing ALL required functions by user. There is INTERFACE for class that requires to implement all methods. > I should have written "remove the SessionHandler class". As I wrote, > > user may > > extend SessionHandler class. > > I don't think this is a good idea. There are valid uses of this, and > there's code using it. Removing it does not achieve any goal as far as I > can see. > Goal is removing abused class usage.(cleanup) e.g. Refer to PHP_FUNCTION(session_set_save_handler). Advocate OOP best practice. i.e. Use INTERFACE when user is required to implement all required methods. And provide good API (both internal/user). e.g. Missing functions like user serializer, gc, create_id. Some cleanups have done in my last PR, but there are more cleanups to do. > > However, defining user session class as > > class MySession extends SessionHandler {} > > have no merit. Users must implement required methods to be useful. > > I'm not sure why you say that - if they don't implement any methods, > wouldn't that class work exactly as the native handler? Isn't the native > handler useful? If user need native handler, they should use it directly. IMO. Anyway, it seems it's better to propose user serializer first, then SessionHandler removal. (I would like to cleanup things first, then add new features one by one though. Session module can be simpler with a little compatibility sacrifice.) I would like to discuss one by one. Shall we discuss user serializer? What do you think? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net