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

Reply via email to