Rename ServerSpanNaming to HttpRouteHolder - #5211
Conversation
|
|
||
| /** An interface for getting the {@code http.route} attribute. */ | ||
| @FunctionalInterface | ||
| public interface HttpRouteGetter2<T, U> { |
There was a problem hiding this comment.
It's not obvious to me that it's better but as a reminder, the JDK idiom is to use Bi, not 2, e.g. BiFunction BiConsumer. I guess here our naming is constrained by having a fixed Context param along with the arbitrary ones
There was a problem hiding this comment.
That being said, I guess having these types is to avoid capturing lambdas, but are we sure the performance improvement is really enough to avoid the simpler Supplier<String> or Function<Context, String>? With inlining and such it's always hard for me to really understand how bad a capturing lambda is
There was a problem hiding this comment.
It's not obvious to me that it's better but as a reminder, the JDK idiom is to use
Bi, not2, e.g.BiFunctionBiConsumer
Changed it HttpRouteBiGetter (because of ToDoubleBiFunction in the JDK)
There was a problem hiding this comment.
With inlining and such it's always hard for me to really understand how bad a capturing lambda is
I opened #5215 (targeted to Stable API project) to make sure that this is an optimization worth keeping
* Rename ServerSpanNaming to HttpRouteHolder * HttpRouteBiGetter
3 participants
... and
ServerSpanNameSupplier/ServerSpanNameTwoArgSuppliertoHttpRouteGetter/HttpRouteGetter2- I used the functional libs/languages as an inspiration here, they usually have interfaces with names likeFunction2(e.g. Kotlin).Another part of #442