Hi! > 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. > My point is SessionHandler class is (almost) useless as a CLASS. It I think we established it is not useless. It may not be useful for you, but may be useful for other people. Creating a large BC break for a reason that something is not useable for someone is not a good idea, I think. I do not see any benefit such action would produce. > Goal is removing abused class usage.(cleanup) e.g. Refer to The action should not be its own goal, and I don't see how it's "abused". So far we have seen an example of use which you recognized as reasonable, and which is endorsed by our own manual,, and no examples of abuse. > PHP_FUNCTION(session_set_save_handler). > Advocate OOP best practice. i.e. Use INTERFACE when user is required to > implement all required methods. There's no OOP best practice that says you can not extend classes and override some of its methods in order to modify parent's behavior. On the contrary, doing this is one of common OOP practices. > And provide good API (both internal/user). e.g. Missing functions like > user serializer, gc, create_id. If you want to provide additional API, by all means please make an RFC. But I do not see how removing this class is required for providing any API. > If user need native handler, they should use it directly. IMO. I do not see any reason for that. You can clearly use native handler and add modifications for it. In fact, that is exactly why that class exists. > I would like to discuss one by one. Shall we discuss user serializer? > What do you think? Again, if you want to propose new feature, by all means please do. I still don't see how it requires removing existing classes. This is a very big BC break and requires very big gain to justify, and so far the gain was not shown I think. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
