tracing-tracy: replace baked-in config fields with a Config trait
#91
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
In the 2nd commit I went ahead and added an example of how |
nagisa
force-pushed
the
nagisa/config-struct
branch
from
bb60392
to
300b61d
Compare
SUPERCILEX
reviewed
Jan 6, 2024
| type Formatter: for<'writer> FormatFields<'writer> + 'static; | ||
|
|
||
| /// Use a custom field formatting implementation. | ||
| fn formatter(&self) -> &Self::Formatter; |
There was a problem hiding this comment.
I wish there was a way to specify a default here. Sadly not much progress: https://rust-lang.github.io/rfcs/2532-associated-type-defaults.html
There was a problem hiding this comment.
I wish it was possible too, however even with ATDs it wouldn’t be possible as the method returns a reference to &self and traits do not have access to fields. Achieving this would need something like rust-lang/rfcs#1546.
| /// report the issues in whatever way they wish to. | ||
| /// | ||
| /// By default a message coloured in red is emitted to the tracy client. | ||
| fn on_error(&self, client: &Client, error: &'static str) { |
There was a problem hiding this comment.
Ooooooh, this is quite a nice flexibility improvement.
SUPERCILEX
reviewed
Jan 6, 2024
This allows users to more flexibly adjust the behaviour of the tracing layer. My favourite examples are actually an ability to implement this structure for some other serialization format that holds the application-wide config. That way people do not need to litter their application set up code with accesses to their configuration, conversion and other concerns. But with this if people want constant evaluation for performance critical applications, now they can do it too.
In practice I have found that, whenever a library provides an ability to configure through a trait generic and then provides a basic runtime cofniguration convenience-type, the convenience type ends up being dropped in favour of a manual implementation pretty quickly. So it seems like a not-terrible-idea to just push users to the trait immediately? And we don’t need to figure a good design for a compile-time configuration type… Might still go back on this decision, idk.
nagisa
force-pushed
the
nagisa/config-struct
branch
from
744afce
to
a9e4c24
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows users to more flexibly adjust the behaviour of the tracing layer. My favourite examples are actually an ability to implement this structure for some other serialization format that holds the application-wide config. That way people do not need to litter their application set up code with accesses to their configuration, conversion and other concerns.
But with this if people want constant evaluation for performance critical applications, now they can do it too.