Should we consider having an interface for all "collection" like objects

[bogdandrutu]

Right now in Otel API we have few objects that look like a type of custom "collection" and would be good to follow the Java standard of exposing this as an interface (see for example Collection/List/Set/etc.):

• Attributes
• Labels
• Baggage
• TraceState

And methods are:

• isEmpty
• size
• get
• forEach
• asMap
• toBuilder

We may not necessarily include all of them in the interface, but would be good for users to know when an object is like that.

[anuraaga]

This came to mind, but I don't expect users to ever need to indicate with these in a generic way with an upcast - I would consider code like Map<String, BaggageEntry> baggage = Baggage.builder().build() to never be correct (the baggage exists to be used as baggage, not a generic collection) and it's good it's a compile time failure. This is the main reason for using asMap instead of directly implementing Map, and I guess would be the same for any other custom collection interface we defined.

[bogdandrutu]

I don't think about communicating in a generic way, but easier to remember the API. "This object is a OtelCollectionLike so it has the APIs x,y,z,t...."

[anuraaga]

Yeah I see that, but it does make it compilable to do something like OtelCollectionLike baggage = Baggage.builder().build() which seems like a net loss? I think the primary reason for generic interfaces is to allow the object to be used generically, not for API remembering, so the user will look for methods that accept OtelCollectionLike, which I don't think we have / want. We could add later though if we did add actual generic functionality though.

[bogdandrutu]

We can probably mark this as after GA because we can do it in backwards compatible way, so I agree that we can do it later