@ikitommi Surprising. But I meant you could write your own version of derived-map that's basically a simple wrapper for map functions (assoc/get/dissoc) with an inlined switch on the correct piece of code and fallback on normal fns for extras (like extmap for records). But yeah protocols are easier but I have the feeling that's not something that would be added to ring without resistance (I could be wrong)

also I imagine some adapters might not do caching of the returned values (ex when parsing headers) while others do. So sometimes acting as a simple method proxy might not be the best thing to do, but I guess that's a concern for the implementer of the protocol (or whatever is used)

the def-derived-map seems to emit fast access functions for all fields (`.get__0`...). Immutant exposes the ServerExchange as a key so we could extend the Immutant Request Type to satisfy a new common protocol. I think this is best of both worlds: a map-like request to be compliant with the ring spec, a zero-copy construction and can be used via (the new) protocols for really fast access.

Could add the new protocols to in reitit-ring and rewire the internal middleware & interceptors to use those. And a new reitit-immutant module to make it fast with Immutant.

Aleph doesn't expose the Netty Request, so would need a PR for it to work. Could try that after seeing if the perf gains are visible in the real usage.

getting the protocols into ring.... Wouldn't break anything and the default would be to make maps satisfy those. Would like to hear what @weavejester thinks about this.

btw, didn't know about __extmap, thanks.

@ikitommi What protocols?