Open rgrinberg opened 9 years ago
That's a good idea...I'd be very much in favour of using those signatures to "consistency check" the backends.
On 8 Nov 2014, at 22:35, Rudi Grinberg notifications@github.com wrote:
I know we've ruled against #119 https://github.com/mirage/ocaml-cohttp/pull/119 but how about resurrecting an lwt/async agnostic signatures for these functions and simply using them for type checking. While still expanding all of the aliases to have decent docs.
Did the change to Body, but not sure it isn't just bikeshedding -- the Async backend is still different.
Yeah that's probably the least important change. Imo the naming of things is what's really ugly now. Unfortunately, cohttp has quite a few downstream users for a "beta" library. I suppose we can keep always keep aliases for the old stuff.
What about the deal with labelled arguments in the lwt server api. E.g. it takes unit
as a last parameter in every call while Async has the last parameter non labelled? The former is much more consistent, while the latter is "prettier".
See also: Lack of post_form
in async: #235.
As we've said before, async and lwt backends should follow the conventions of async and lwt but in some cases we have some pointless differences. For example:
?headers ?flush
or?flush ?headers
?respond_string
vs.respond_with_string
(I prefer the former)f
first without a label.Cohttp_lwt_body
vs.Cohttp_async.Body
(I don't have a preference)I'm sure there's more - this is just after a quick glance.
I know we've ruled against #119 but how about resurrecting an
lwt/async
agnostic signatures for these functions and simply using them for type checking. While still expanding all of the aliases to have decent docs.