feature: remove [scheme] from requests#1086
Conversation
| let empty = Uri.of_string "" in | ||
| let empty_base = Uri.of_string "///" in |
There was a problem hiding this comment.
A Uri.t is a fairly heavy record - I just noticed both of these can be lifted into constants at the toplevel and not reallocated every request
There was a problem hiding this comment.
Indeed. I wonder if we should just get rid of this function altogether and just introduce separate functions to extract the Uri components that can be safely extracted out of the request.
There was a problem hiding this comment.
Probably just better to 'deallocationise' this library separately. I actually wanted to use it to test out the JS with-extensions tree to see how well local annotations would do in some places here...
There was a problem hiding this comment.
Sure, though I think this function cannot be be used in a low allocation context anyway. Many of the components this function is returning can be extracted without any allocation at all. While the Uri.t this function returns will always be allocated - even if it is only done once.
There was a problem hiding this comment.
Yes, it would need changing the Uri library as well... the accessors there could be more lazy. That library's design hasn't changed for about a decade -- about high time for a refresh!
This makes it so that [Request.make ~uri |> Request.uri] will no longer return the same URI as [uri]. Also, this property was never preserved with respect to other URI fields. Signed-off-by: Rudi Grinberg <me@rgrinberg.com> <!-- ps-id: eab21598-332e-4541-9530-fe5ca05e2d06 -->
f2932ca to
47a77bc
Compare
This makes it so that [Request.make ~uri |> Request.uri] will no longer return the same URI as [uri]. Also, this property was never preserved with respect to other URI fields.
cc @MisterDA
Signed-off-by: Rudi Grinberg me@rgrinberg.com