On 13.10.2020 at 18:01, Sara Golemon wrote: > On Mon, Oct 12, 2020 at 7:55 AM Christoph M. Becker <cmbecke...@gmx.de> > wrote: >> >> 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. >> > > Ditto all this. When we converted resource<hash context> to > object<HashContext> I fully intended to propose adding methods on the > context using pretty much exactly the API you describe. Digests lend > themselves quite well to this, tbqh. I did want to separate the tech debt > of removing resources from the feature creep of adding an OOP API though, > and with that release already quite featurefull, plans to expand it fell by > the wayside. > > Happy to co-author an RFC with you if you'd like to get involved directly, > or I can just pick up the ball and run with it if you'd rather make the > feature request then step back.
Please go with this, if you like. Note that I didn't make the feature request; I just support it. :) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php