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 intern...@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.coll...@gmail.com> wrote: > > On Mon, 12 Oct 2020 at 15:20, G. P. B. <george.bany...@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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
