From an SDK consumer viewpoint, would it be preferred to return an *`array`* of strings or a *`colle...

# multiplatform

[Sylvain Patenaude]

From an SDK consumer viewpoint, would it be preferred to return an array of strings or a collection of strings? Potential consumers (other than Koltin itself) could be Java, Swift, Objective-C, React Native, Xamarin, etc.

[Kris Wong]

that depends on how the data is intended to be consumed

[Kris Wong]

or stated another way, what use cases the API is optimized for

[streetsofboston]

Use a type, for the return-value, that is an interface/protocol that is as small as possible.

If the returned ‘collection’ just needs to be iterable, the return-type should be a Collection. If it needs to be accessed by index, the return-type should be a List or Array (but not a particular implementation/sub-type of List or Array), etc.

It depends, but make the return-types interface/protocol as small as possible but large enough to be functional for your SDK consumers, decoupling your SDK’s API from its implementation.

[Kris Wong]

☝️

[Sylvain Patenaude]

To give a little more context, one function of the SDK would return a collection (or array) of UUIDs (or GUIDs) as strings (since there's no Kotlin Guid type). For now I don't know all the potential usages, but I guess that would possibly include:

• Iterating through them to convert them in true GUID types in the consumer programming language
• Iterating through them to combine them with another bunch of UUIDs
So consumers shouldn't access them by index I think.

[Sylvain Patenaude]

So that would point to using a Collection.
However, if I want to make the interface/protocol as small as possible, that would point me to? Array<String>?? Seems that I may have conflicting factors.

[Sylvain Patenaude]

Not that thrilled to represent GUIDs as Strings but at the same time, I think most languages that support a Guid type have a constructor that builds a Guid from a valid string.

[streetsofboston]

The return type would be Collection<String> (or Collection<Guid> if that is possible) based on your use-case (no need to access them by index).
If you want to make sure that the Strings and Guids are unique, and convey that to your SDK consumer, use Set<String> instead.

[Sylvain Patenaude]

Indeed, Set<String> would be an option. In the end, I don't think the specific type of "collection" (Array, Collection, Set, List) I will use in Kotlin will matter that much for my SDK.