Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.182 as permitted sender)
Message-ID: <54C2DE03.6090708@gmail.com>
Date: Fri, 23 Jan 2015 15:49:23 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXZHP3-uHaXJW_QkEva8wECXwu9C3f=v+xGTVodtyCvQKw@mail.gmail.com> <54C1D562.1080402@gmail.com> <CAGa2bXZwdQeZHTE4G-6YmNPwT4xmjY9nmGTi_yDPse9vVAKm_w@mail.gmail.com> <54C1EE77.7040000@gmail.com> <CAGa2bXab+YhAw5P8u2YaHAm2+WbSmn5qs1dsMFNsVEwtns2qpg@mail.gmail.com>
In-Reply-To: <CAGa2bXab+YhAw5P8u2YaHAm2+WbSmn5qs1dsMFNsVEwtns2qpg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Removing base class from session handler
From: smalyshev@gmail.com (Stanislav Malyshev)

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
smalyshev@gmail.com