Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112043
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>
 <CAFPFaMJ0GddrCXRtP1UT_s9myEeQvZ6RnNhL4Ov9cN5DdEBbKQ@mail.gmail.com> <CALKiJKpXM=ObDQ3uP0se_0qcy=_zRJMM9Crgjg-qgEKOJ2KcuQ@mail.gmail.com>
In-Reply-To: <CALKiJKpXM=ObDQ3uP0se_0qcy=_zRJMM9Crgjg-qgEKOJ2KcuQ@mail.gmail.com>
Date: Tue, 13 Oct 2020 11:43:38 +0200
Message-ID: <CAJmy8YEu+N3NB6WAkvTbY7LG8x59c0VB0_rr8iHwTzhpYeDr_Q@mail.gmail.com>
To: internals@lists.php.net
Cc: "Kingsquare.nl - Robin Speekenbrink" <robin@kingsquare.nl>, Rowan Tommins <rowan.collins@gmail.com>, 
	"Christoph M. Becker" <cmbecker69@gmx.de>, "G. P. B." <george.banyard@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: want an Object-oriented interface for HashContext
From: divinity76@gmail.com (Hans Henrik Bergan)

i know this is unrelated to the thread at hand, but am i really
supposed to find the email of everyone who has replied to a thread,
and add them all manually to cc? (or is it sufficient to just send it
to internals@list.php.net ? ) (also funfact, it seems if you regex the
innerHTML after opening an email on gmail.com , the innerHTML contains
*every single email you've ever interacted with*, i found 680 emails
when checking the innerHTML for this thread, quite the surprise)


@Christoph M. Becker

> I think the
> method names should use camel-case (e.g. ::updateFile() instead of
> ::update_file())

that's fine by me (could mention that PHP already use both approaches, examples:
procedural: numfmt_format_currency
OO: NumberFormatter::formatCurrency
procedural: MySQLi::affected_rows
OO: mysqli_affected_rows()
)

> it might be appropriate to rename ::final() to
> ::finalize()

that's fine by me
(personally i'd prefer a str() function which didn't finalize anything,
but i guess that's a separate issue altogether,
besides, userland users can work around it with hash_copy() when it's
really needed)

@robin

> 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 ;)

yes a composer package could easily wrap the current api,
and it doesn't have to be done in core, but i would prefer it to be in the core,
and the current HashContext class looks..
underdeveloped/underutilized/untapped/unfinished/awkward
(don't know what the correct word is, English isn't my native
language, but something like that)
 but as G. P. B. mentioned below, there's a reason for that: it used
to be a resource.


@ G. P. B.

> 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]

interesting

> 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.

neat, TIL (that leaves the question of what happens to is_resource()
and all the code using it, but
 that's a different topic altogether ^^ )

> 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.

in this case i think some version of the OO api would be better in every way
(since even with the current procedural api, you still need to carry
around the HashContext object anyway,
i can't think of any good reason it shouldn't have the functionality
embedded as methods, instead of using
5 global functions to manipulate it.. then again, maybe the same can
be said for nearly all resources)

> This can also lead us to deprecate the procedural API in favour of said new OO API.

if there is interest in deprecating the procedural one, i guess it'll
have to start throwing
E_DEPRECATED in some 8.x release, and be removed in 9.0.0?

@Rowan Tommins

> I'm not that familiar with the hash functions, so
> can't really comment whether I would expect them to be usable "out of the
> box" or just as primitives for a higher-level wrapper.

i'd expect it to be "usable out of the box" (and it is, but...clunky)







On Mon, 12 Oct 2020 at 16:30, Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> On Mon, 12 Oct 2020 at 15:20, G. P. B. <george.banyard@gmail.com> wrote:
>
> > Therefore I am not sure what composer and a userland package can bring...
> >
>
>
> As an example of this general approach, the MongoDB extension provides a
> minimal set of low-level "driver" functionality, and the official userland
> package builds on top of these to create a richer set of APIs. That means
> the majority of development takes place in the userland library, making it
> easier to maintain, easier for users to keep up to date, and so on.
>
> That's not always the appropriate approach, though - some built-in
> functionality is useful precisely because it's "batteries included", like
> the password_* functions. I'm not that familiar with the hash functions, so
> can't really comment whether I would expect them to be usable "out of the
> box" or just as primitives for a higher-level wrapper.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]