You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And we simplify even further if we implement a NoOpSender. Instead of injecting an optional event sender (opt_http_stats_event_sender) in the constructor we can inject a null sender.
The null sender does nothing.
Factory functions can return always a "real" sender or the NoOpSender:
IMPORTANT!: Please read this comment before implementing this issue.
If events are always enabled, this issue does not make sense.
I think we should be able to:
Enable/disable events
Enable/disable stats
Independently.
In some cases, where only performance is crucial and the user does not care about stats, it could be convenient to disable events and stats altogether.
The NoOpSender is not a good idea because if we always enable events (even when we don't want to process them), the performance could be similar with the current events (there are simple enums). However, I plan to enrich the events. With "fat" events, the NoOpSender would have the cost of building the event. That requires copying objects in memory.
NOTICE: Enabling stats requires enabling events, but we can check that dependency while checking the loading configuration. We have other similar checks.
There are some functions like this:
We can simplify those functions:
And we simplify even further if we implement a
NoOpSender
. Instead of injecting an optional event sender (opt_http_stats_event_sender
) in the constructor we can inject a null sender.The null sender does nothing.
Factory functions can return always a "real" sender or the
NoOpSender
:Alternatively:
This was the sender is always available and we can remove the "if" condition from:
The text was updated successfully, but these errors were encountered: