Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112038
MIME-Version: 1.0
References: <CAJmy8YGSWkzEu1g2c9o=+5jSHEXGb=vW0dKcEwrHtKGPyC+eCA@mail.gmail.com>
 <ffa2774b-757e-879d-7bfa-dc554e4cc04a@gmx.de> <CADq_CxrGRb27DCH-jPDNOQaO7z+ka0bO-WfwhpgTQMp4aeys7A@mail.gmail.com>
In-Reply-To: <CADq_CxrGRb27DCH-jPDNOQaO7z+ka0bO-WfwhpgTQMp4aeys7A@mail.gmail.com>
Date: Mon, 12 Oct 2020 15:20:10 +0100
Message-ID: <CAFPFaMJ0GddrCXRtP1UT_s9myEeQvZ6RnNhL4Ov9cN5DdEBbKQ@mail.gmail.com>
To: "Kingsquare.nl - Robin Speekenbrink" <robin@kingsquare.nl>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, Hans Henrik Bergan <divinity76@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b2a51005b179ff9f"
Subject: Re: [PHP-DEV] Re: want an Object-oriented interface for HashContext
From: george.banyard@gmail.com ("G. P. B.")

--000000000000b2a51005b179ff9f
Content-Type: text/plain; charset="UTF-8"

On Mon, 12 Oct 2020 at 15:01, Kingsquare.nl - Robin Speekenbrink <
robin@kingsquare.nl> wrote:

> Op ma 12 okt. 2020 om 14:55 schreef Christoph M. Becker <cmbecker69@gmx.de
> >:
>
> > On 12.10.2020 at 13:49, Hans Henrik Bergan wrote:
> >
> > > something like
> > >
> > > $result = (new
> > HashContext("SHA1"))->update($str1)->update($str2)->final();
> > >
> > > (userland sample imp: https://3v4l.org/lXd3u )
> > >
> > > I tried asking on the bugtracker (
> https://bugs.php.net/bug.php?id=80221
> > ) ,
> > > but was told to ask on this mailing list instead.
> >
> > Thanks for bringing this up on the mailing list!
> >
> > I basically very much support a proper OOP interface, but I think the
> > method names should use camel-case (e.g. ::updateFile() instead of
> > ::update_file()), and it might be appropriate to rename ::final() to
> > ::finalize().  More bikeshedding regarding the method names, and maybe
> > their signatures might be in order.  We do not necessarily have to make
> > these methods aliases of the existing functions, although that's of
> > course possible.
> >
> >
> Dear all,
>
> As a user/developer of the language itself: it seems to me this is what a
> package using composer could easily fix right? Does this really have to
> land in core to be used in the wild? With the proliferation of all the up
> and coming features and performance improvements it seems to me like these
> types of improvements using lower level PHP interfaces / native functions
> have no merit in core itself?
> (packagist / composer packages don't always have to be full frameworks /
> large solutions right IMHO)
>
> This would also allow the developer to pick and choose a personal style and
> we don't have to flood the internals with bikeshedding ;)
>
> Robin Speekenbrink
>

The reason for the non existence of OO APIs is that until recently these
objects
were resources, HashContext is only an object since PHP 7.2. [1]
We performed a bunch of resources to opaque object conversion in PHP 8.0
and the plan
is to migrate *all* resources to objects. [2]
That's the reason why the procedural API exists, and as most of these
opaque objects are
marked as final (among other things) to be drop-in replacements of
resources while the design
of the OO API is left at a later time.

Therefore I am not sure what composer and a userland package can bring when
one potential
avenue to explore is introducing a more thought out and/or (possibly)
better API which was hindered
by the technical limitation of using a resource.
This can also lead us to deprecate the procedural API in favour of said new
OO API.
This does not need to happen for *all* resource to object conversions but
it's something to keep in mind.

Moreover, I prefer to have the API be part of the relevant extension than
tugged away in some random
composer package.

Best

George P. Banyard

[1] https://wiki.php.net/rfc/hash-context.as-resource
[2] https://github.com/php/php-tasks/issues/6

--000000000000b2a51005b179ff9f--