On Mon, 12 Oct 2020 at 15:01, Kingsquare.nl - Robin Speekenbrink <
ro...@kingsquare.nl> wrote:
> Op ma 12 okt. 2020 om 14:55 schreef Christoph M. Becker <cmbecke...@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
