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:
