-
-
Notifications
You must be signed in to change notification settings - Fork 454
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
feat: Make tracing object fluent #1381
Conversation
6e09e2e
to
ff57bce
Compare
I really like how this would improve our API. On the other hand, we will force people to update all their instrumentation code when they upgrade to 4.0. |
Why would they? The old code still works with this change. In my description, both code blocks work perfectly fine after this change 😄 The only thing is that people extending our classes (read: |
I would like to have a discussion about this in a different issue, where we could discuss annotating stuff as |
Closing for now but keeping the branch for later 🙂 |
Closing this in favor of #1601. |
This could make writing tracing code easier and more readable depending on your preference.
The upside is that this unlocks a fluent way of writing. I don't think there are any actual downsides (apart from BC).
I believe this is a backward incompatible change, especially
Span
is not a final class so I don't think we can make this change in 3.x but maybe this is a good start for 4.x and allows us to make the tracing code simpeler/shorter to use. Possibly we could already convert the final classes but not a 100% sure if that is also a BC.If we think this is acceptable and a good change I would propose that going forward (possibly starting with 4.x) to make all future APIs fluent where it makes sense.
A small example partly taken from the laravel codebase:
Before:
After: