Re: [RFC] session_start(), read_only, lazy_write; Take 2

Hi, >> Well, I certainly can't understand why you think that a separate function would be >> counter-intuitive or that it won't produce easily-read code. With >> what we currently have, chances are that the following line would be seen quite often: >> >> session_start($options); >> >> What do you understand from that line (regardless of whether 'read_only' is in >> $options or not)? I see "start a session with some options". This is >> again where the closing part is lost, nothing implies that anything but "start a >> session" would be performed, as an action. While on the other hand: >> >> session_start_close($options); >> >> I'm quite certain that everybody would have a better understanding of what this line >> does, simply because it's explicit. >> Yes, it is nitpicky and it's nothing but semantics, but semantics are important. :) > > To answer your question, as a single line yes, it read more clearly in regards to that 1 > characteristic of the session, but... > when I wrote my mockups I ran through a bunch of these scenarios and found myself wrapping > session_start and what you call session_start_close > with a php end user function so I could consolidate my calls to start a session into a common > interface that accepted an argument to tell the function > which php native function to call to start the session. Maybe that's just me but I think > this will in fact become common in codebases which liberally use > both types of sessions starts. I went down this path pretty quickly when running through use > cases with my existing codebases and it felt unnecessarily > restrictive to me considering it was solved by the passing as an option to session_start > solution Yasuo had suggested at that time. If you don't have to wrap the function call, you'll have to wrap the option somehow, you can't escape from that. Thankfully it's something that's only written once within a single application, hence why it should be more explicit and easily recognizable. Otherwise, everybody is entitled an opinion and their own preferences, so we'll never agree on which one feels better in general. > The separate function approach also doesn't account for adding more things like this in > the future or to chain those options together in the same session > without creating a new function for every permutation possible for any new options we add > unless this acts as a one-off and all future options like this > are added as flags passed into via the options array. In other words, as a rule "make it a > function not an option" doesn't scale if we add more stuff like this > in the future. > > The separate function approach also doesn't cleanly (cleanly is my subjective opinion) > support the option having some value outside of TRUE, > i.e. session_start(['read_only'=>FOO]) might be a viable option at some point. I don't see the potental for neither another similar option (representing an action instead of mode) or another possible value. Pretty much every session-related action has its own function now, I consider this one to be an edge case. Cheers, Andrey.