feat(p3): return owned request-options on consumption
#160
Conversation
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
|
Makes sense to me |
|
I've already merged this, but I just had one more thought. What if we did something like this: record request-parts {
method: method,
path_with_query: option<string>,
scheme: option<scheme>,
authority: option<string>,
headers: headers,
options: option<request-options>,
body: option<body>,
}
resource request {
// ...
into-parts: static func(this: request) -> request-parts;
from-parts: static func(parts: request-parts) -> request;
}(and likewise for That could make request/response-modifying middleware easier to write -- just call Thoughts? |
Assuming that the cost of moving the field values is negligible, I think that would work great - I was thinking about doing something similar, but opted for the most minimal, incremental change I could come up with. |
|
If we're concerned about the overhead of lifting and lowering all the fields, we could do something like this: record request-parts {
request: request, // Request with no headers, options, or body (i.e. just method, path-with-query, etc.)
headers: headers,
options: option<request-options>,
body: option<body>,
}
resource request {
// ...
into-parts: static func(this: request) -> request-parts;
from-parts: static func(parts: request-parts) -> request;
} |
Currently, there's no way to acquire the owned
request-optionsfrom therequest, return them as part of theinto-partsalong the other moved resources