Andrey,
> The issue is exactly that it would be easy to not understand what 'read_only' does.
> Nowhere have I said that the functionality itself is dangerous
> or that it is not useful, exactly the opposite - I love the idea, it's pretty neat. My
> problem is with how it is named, and that's what the RFC talks
> about. :) Unless I'm mistaken, you already mentioned in another thread that it is you who
> suggested the 'read_only' name, so I guess it's natural
> that you don't see a problem with it and that it seems descriptive and self-evident to
> you.
I only suggested the functionality, not the name of the option. Interestingly enough I originally
suggested it as a new function just like you suggest
but Yasuo asked me if I thought it would be better as an option. After mocking up some code using
both I found the option passed to session_start
to give me more flexibility in my solution design and I found it more intuitive so I agreed it was
better as an option passed into session_start and
not a function.
...
>> On your point about, "Maybe, if session_start() didn't accept mode parameters,
>> that would've been fine. However, session_start() also accepts
>> all session.* INIs + 'lazy_write' and all of those are modes of operation and not
>> additional actions per se. So that makes it not only strange, but
>> also inconsistent", you've lost me -I don't see a problem. If I call
>> session_start and I can pass in a bunch of options about how the session will
>> act in this call stack that seems like the best and most pragmatic solution. The
>> distinction between modes of operation and additional actions
>> seem like a semantic nitpick that end-users wouldn't intuitively understand. In other
>> words, it seems counter-intuitive to work some other way
>> and wouldn't produce more easily read/written code to have it different.
>
> 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.
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.
Best,
Bill Salak