Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81052
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.46 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54C1EE77.7040000@gmail.com>
References: <CAGa2bXZHP3-uHaXJW_QkEva8wECXwu9C3f=v+xGTVodtyCvQKw@mail.gmail.com>
 <54C1D562.1080402@gmail.com> <CAGa2bXZwdQeZHTE4G-6YmNPwT4xmjY9nmGTi_yDPse9vVAKm_w@mail.gmail.com>
 <54C1EE77.7040000@gmail.com>
Date: Sat, 24 Jan 2015 06:56:08 +0900
Message-ID: <CAGa2bXab+YhAw5P8u2YaHAm2+WbSmn5qs1dsMFNsVEwtns2qpg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c11a989247e6050d58dd50
Subject: Re: [PHP-DEV] Removing base class from session handler
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c11a989247e6050d58dd50
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Fri, Jan 23, 2015 at 3:47 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > User may extend SessionHandler class like
> >
> > class MySession extends SessionHandler {}
> >
> > but user cannot extend base class(SessionHandler) capability because
> > user script
> > cannot access to PS(mod_data).
>
> Not sure what you mean by that. Absence of access to PS(mod_data)
> certainly doesn't mean the user can not extend it's function, e.g. the
> manual demonstrates EncryptedSessionHandler - is there something wrong
> with that?  Of course, there can be many more examples of it.
>

This is the only reasonable use I know. I would to write user
serializer(read/writer)
handler for it.

User serializer is much powerful. Users may implement JSON/BSON/YAML/XML/
whatever serialization methods, along with encrypt/decrypt,
compress/uncompress
session data.
NOTE: Session module always serialize session data with serializer, user
cannot
implement JSON/BSON/etc without native serializer.

My point is SessionHandler class is (almost) useless as a CLASS. It
requires
implementing ALL required functions by user. There is INTERFACE for class
that requires to implement all methods.

> I should have written "remove the SessionHandler class". As I wrote,
> > user may
> > extend SessionHandler class.
>
> I don't think this is a good idea. There are valid uses of this, and
> there's code using it. Removing it does not achieve any goal as far as I
> can see.
>

Goal is removing abused class usage.(cleanup) e.g. Refer to
PHP_FUNCTION(session_set_save_handler).
Advocate OOP best practice. i.e. Use INTERFACE when user is required to
implement all required methods.
And provide good API (both internal/user). e.g. Missing functions like user
serializer, gc, create_id.

Some cleanups have done in my last PR, but there are more cleanups to do.


> > However, defining user session class as
> > class MySession extends SessionHandler {}
> > have no merit. Users must implement required methods to be useful.
>
> I'm not sure why you say that - if they don't implement any methods,
> wouldn't that class work exactly as the native handler? Isn't the native
> handler useful?


If user need native handler, they should use it directly. IMO.

Anyway, it seems it's better to propose user serializer first, then
SessionHandler
removal. (I would like to cleanup things first, then add new features one
by one though.
Session module can be simpler with a little compatibility sacrifice.)

I would like to discuss one by one. Shall we discuss user serializer? What
do you think?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c11a989247e6050d58dd50--