Reordering new API's that have a libctx, propq

[SHANE LONTIS]

Thanks for the writeup..

> My view is that the importance of arguments is what sets their order - and that is why for the TYPE functions the TYPE pointer
> comes first. We could have just as easily specified it as last or some other order, but we didn’t.

Isn’t that the order that the fetch is in if it changes to what it is in the PR? I would argue that the algorithm is the most important parameter in the fetch.

Deciding what argument is more ‘important’ is not always easy either.
If we are doing an operation such as a get or load and it needs a whole lot of input params in order to return something,
then aren’t they more important/ or just as important as the libctx,propq - (since the libctx,propq is just used normally to fetch something)?
This then means the libctx ends up last, or maybe in the middle again.

Also it is quite common for the new() methods (such as for X509) to need both the libctx and propq..
The X509 object gets passed to an d2i method that internally needs to do fetches (SHA1) and cache.

Shane

> On 5 Sep 2020, at 5:09 pm, Tim Hudson <tjh at cryptsoft.com> wrote:
> 
> My view is that the importance of arguments is what sets their order - and that is why for the TYPE functions the TYPE pointer
> comes first. We could have just as easily specified it as last or some other order, but we didn't.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200905/1f66917f/attachment.html>