Re: Revert session_serializer_name(), session_gc()

Hi Yasuo, On Wed, Mar 12, 2014 at 12:37 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Andrey, > > On Tue, Mar 11, 2014 at 10:37 PM, Andrey Andreev <narf@devilix.net> wrote: >> >> I just saw this in the 5.6-alpha1 changelog: >> >> - Implemented Request #54649 (Create session_serializer_name()). >> (Yasuo) >> ... >> - Implemented Request #11100 (session_gc() function). (Yasuo) >> >> >> I didn't find an RFC and I don't know a way to search for a discussion >> on internals (Google doesn't find one). >> >> session_serializer_name(): >> https://bugs.php.net/bug.php?id=54649 >> >> I don't think that this should've been implemented, especially with >> the reasoning from the feature request ... The same could be applied >> to all session ini options and especially now since session_start() >> accepts them, it's useless IMO. >> >> session_gc() was added in a similar fashion: >> https://bugs.php.net/bug.php?id=11100 >> >> There's already a comment about how the same thing can be achieved by >> overloading SessionHandler::gc(), but a user could also just alter >> session.gc_divisor, session.gc_probability to ensure that the garbage >> collector is started. > > > Users want to have contorl *when* gc is performed rather than luck. This is > reasonable. IMO. I like control, it's nice and *I already have it*: ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 1); >> >> And while session_serializer_name() is just redundant, session_gc() >> could cause performance issues. > > There is session_module_name(), why not session_serializer_name()? Why not session_cookie_lifetime()? Why not session_cache_limiter()? Why not session_entropy_file()? etc. "Why not" is never a good argument in programming and really, when is the last time that you've seen something accepted here on internals because of "why not"? I'd rather question if session_module_name() is useful, or any function that's an alias for ini_set('something', ...). > Many 3rd party save handler implements many serializer. I haven't seen many. In fact, I've seen none. > session_gc() is nothing to do with performance. Users may abuse. The same > argument applies to gc probability. The problem is, users WILL abuse and that's bad. Think of what the manual page would say about that function. Something in the lines of: Calls the session garbage collector, ignoring session.gc_probablity and session.gc_divisor. What does that say to an inexperienced and even to the intermediate user, who doesn't even know what GC is? "Hey, this collects garbage! It's nice to clean things up, I should always call it!" Yet another bad practice spreads. Sure, that *could* apply to gc_probability, gc_divisor, but those are *necessary* options and they are not easy to find unless you are specifically looking for them. > >> I'd strongly suggest that these 2 functions should be removed before >> PHP 5.6 is officially released. > > > These are simple additional APIs. > If your argument applies, there should be number of new RFCs. Actually, if my argument applies - both feature requests should've been ignored. Lots of people make "this would be nice" feature requests without having the knowledge and experience to know if it would really be "nice". That's why there's a bunch of smart people here to take the decisions for them, collectively. I myself have been forced to write an RFC for a smaller and less impactful change, but that's not the point. Both of these functions should've at least been discussed here on internals. And finally, do you assume that there's demand for these features? session_gc() specifically was requested 13 YEARS ago and it didn't even get a "+1" comment in that timeframe. There are people on this list who'd question user demand even if people are tweeting about the feature with fingers crossed that it would be implemented ... these are two that hardly anybody cares about. Cheers, Andrey.