-
Notifications
You must be signed in to change notification settings - Fork 598
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Context from FullEvent #2626
Conversation
@@ -14,17 +14,17 @@ macro_rules! event_handler { | |||
( $( | |||
$( #[doc = $doc:literal] )* | |||
$( #[cfg(feature = $feature:literal)] )? | |||
async fn $method_name:ident(&self, $variant_name:ident { $( | |||
async fn $method_name:ident(&self, $($context:ident: Context,)? | $variant_name:ident { $( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will get to full review later, but why is this |
here? Shouldn't the matching work fine without it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, apparently not, since both $context
and $variant_name
are identifiers, the parsing becomes ambiguous. This could still be done without the bar by defining a event_handler_method!
macro that generates one method at a time and is called inside event_handler!
for each method. It could have a second rule that takes a special @NO-CONTEXT
token at the start which then wouldn't generate a ctx: Context
parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not the best at macro_rules syntax, I'd prefer if this somewhat janky syntax is kept for now and a followup PR could correct it if possible.
e79b8de
to
287739a
Compare
fn update_cache_with_event( | ||
#[cfg(feature = "cache")] cache: &Cache, | ||
event: Event, | ||
) -> Option<(FullEvent, Option<FullEvent>)> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot of the macro invocations here end up using the cache
unconditionally, which I guess somehow works, but it still feels weird to pass in an undefined identifier if the cache
is disabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's overall a bad situation, but I don't think passing Context is any better, because it's still an undefined field access in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't you just inline the macro invocations and feature-flag them? Btw, I noticed there's calls to if_cache!(event.update(cache))
which are almost equivalent to just update_cache!(cache, event)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if_cache!(event.update(cache))
returns None
if cache is disabled, whereas update_cache!(cache, event)
returns ()
. This difference is needed because otherwise the None
would need to be qualified for it's T
. I could of course inline the macro invocations, but that would get very repetitive very quickly and make it a lot harder to read.
ef52b11
to
51afaba
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remaining things are purely internal and can be fixed in a followup PR. LGTM
The macro syntax looks a bit weird as otherwise I run into parsing issues with
ctx
getting parsed the same as a variant name, so I had to put the pipe there as a separator. This is a general clean up as FullEvent is really weird otherwise, and makes genericClient::data
a bit easier (no need for manual clone impl) if we are going to pursue that.