Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73396
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain devtemple.com from 50.116.27.81 cause and error)
To: "'Andrey Andreev'" <narf@devilix.net>
Cc: <internals@lists.php.net>
References: <CAPhkiZyFHshFc56UEHiDFK9k801ztno+xoS82Yf6qAcwiRPg1A@mail.gmail.com>	<010e01cf4788$05f3c5a0$11db50e0$@devtemple.com> <CAPhkiZx8DuDPfks-RNNNunHsjso-9KuwRBor8TjRaK3E10qUiA@mail.gmail.com>
In-Reply-To: <CAPhkiZx8DuDPfks-RNNNunHsjso-9KuwRBor8TjRaK3E10qUiA@mail.gmail.com>
Date: Mon, 24 Mar 2014 17:22:45 -0700
Message-ID: <01c801cf47c0$59acbf20$0d063d60$@devtemple.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIdnyEwmpNQ9DHEQ0tK0vXPLszKbwKiw3ckAhR5pQqaLnT+MA==
Content-Language: en-us
Subject: RE: [PHP-DEV] [RFC] session_start(), read_only, lazy_write; Take 2
From: bill@devtemple.com ("Bill Salak")

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=20
> 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=20
> 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=20
> that you don't see a problem with it and that it seems descriptive and =
self-evident to you.=20

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=20
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=20
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=20
>> 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=20
>> 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=20
>> act in this call stack that seems like the best and most pragmatic =
solution. The distinction between modes of operation and additional =
actions=20
>> seem like a semantic nitpick that end-users wouldn't intuitively =
understand. In other words, it seems counter-intuitive to work some =
other way=20
>> 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=20
> 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=20
> 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=20
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=20
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=20
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=20
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=20
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=20
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=20
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,=20
i.e. session_start(['read_only'=3D>FOO]) might be a viable option at =
some point.

Best,
Bill Salak