Probably we should introduce some interface SpanOrBuilder that is then passed to *AttributeSetter.set instead of Span.
You can workaround by calling key on the setter, but that kinda defeats the purpose.
Follow-up to #758.
Actually, the SpanOrBuilder approach does not work that well, because Builder.setAttribute returns Builder and Span.setAttribute returns void.
Actually, we could provide an interface SpanOrBuilderreturn this in setAttribute).
If we were to do something like this, we'd have to come up with a better name than SpanOrBuilder. I'd rather fix the API, rather than introduce odd patches like this.
I took that name from protobuf, where for each message Foo it generates a Foo, a Foo.Builder and both implement FooOrBuilder. But I'm not married to that name, it was just the first thing that came to my mind.
This was resolved by #1631 I think. 馃憤
resolved with #1631
Most helpful comment
Actually, we could provide an interface SpanOrBuilder if we just changed span to return itself instead of void from setAttribute, which would be a nice usability improvement anyway. Or is this obsoleted by #1130? I think adding some SpanOrBuilder interface would be a relatively small change (basically mostly moving declarations) but still breaking (all Span implementations would need to
return thisinsetAttribute).