Add functions to downcast the transport as a reference or mutable reference #432
Conversation
…erence These functions are useful for getting access to an application-specific custom transport type that has additional methods.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #432 +/- ##
==========================================
- Coverage 46.38% 46.26% -0.12%
==========================================
Files 164 164
Lines 6401 6417 +16
==========================================
Hits 2969 2969
- Misses 3432 3448 +16
☔ View full report in Codecov by Sentry. |
| /// Attempt to get a reference to the trait object as a specific transport type T. | ||
| /// | ||
| /// If the type does not match the original transport type, this will return `None`. | ||
| pub fn downcast_transport_ref<T: Transport>(&self) -> Option<&T> { |
There was a problem hiding this comment.
I'm on the fence about introducing these to the trillium::Conn instead of requiring folks who need this advanced interface drop down to trillium_http::Conn. On one hand, it would be nice to do away with inner and inner_mut, on the other, that might be the right way to indicate to someone that what they're doing is advanced, and eventually gate inner and inner_mut on a trillium feature flag with the semantics of #[cfg(feature = "i-acknowledge-that-i-am-leaving-the-well-trod-path")]
There was a problem hiding this comment.
I'm also on the fence about the interface on trillium_http::Conn<BoxedTransport>. Maybe this usage requires trillium_conn.inner().transport().as_any().downcast_ref() / trillium_conn.inner_mut().transport_mut().as_any_mut().downcast_mut() to make it harder to stumble into?
There was a problem hiding this comment.
I really like the currently documented premise that nothing should require dropping down to the trillium_http::Conn. If you want the top-level methods removed I can do that, but I think going from "if you need to do .inner() that's always a bug" to "do .inner() for various less-common methods" seems less ideal.
There was a problem hiding this comment.
I'm also on the fence about the interface on
trillium_http::Conn<BoxedTransport>. Maybe this usage requirestrillium_conn.inner().transport().as_any().downcast_ref()/trillium_conn.inner_mut().transport_mut().as_any_mut().downcast_mut()to make it harder to stumble into?
Thinking about this: this would still require exposing some new methods, namely transport()/transport_mut() and as_any()/as_any_mut(). However, if you'd prefer this, I can implement it.
|
Checking back in on this: whatever you end up deciding about |
|
I posted #451, which I hope might be more what you're looking for. Let me know if that works for you. |
|
Closing this in favor of the merged #451. |
These functions are useful for getting access to an application-specific
custom transport type that has additional methods.