You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue relates to #2492 but it's not exactly the same. This issue raises the question of what the behavior of a function that accepts both singular and array requests should be with respect to its return type.
For example, let's say hypothetically, the queryRecords interface accepts either a string or an array of strings as its queryTexts property.
I would argue that for someone working with the client, it's more convenient to unwrap the arrays. Given a singular string request, it's not possible for there to be more than one entry in each of the arrays so we can save the client the unnecessary boiler plate of extracting the 0th element. The principle here is that the client matches the shape of the supplied argument. So the shape of the response would be:
I'm not proposing we always unwrap responses that have a single element in them though. For example, if the caller supplied us with an array that had a single element in it, I think that the right behavior is the behavior below:
Again, the principle here being that we're matching the shape of the supplied query. Since the caller provided us with an array, we return them an array of responses, even though there's only a single element.
Alternatives considered
The alternative here is to do what we do today which would be:
The benefit of this approach is that the shape of the response is always consistent with itself. That said, I would argue that consistency between the input and the output of the function is more important than consistency across calls to a function.
Importance
nice to have
Additional Information
No response
The text was updated successfully, but these errors were encountered:
AlabasterAxe
changed the title
[Feature Request]: Match return types to call types
[Feature Request]: Match return types to parameter types
Jul 10, 2024
AlabasterAxe
changed the title
[Feature Request]: Match return types to parameter types
[Feature Request]: Match shape of return type to shape of parameter types
Jul 10, 2024
Describe the problem
This issue relates to #2492 but it's not exactly the same. This issue raises the question of what the behavior of a function that accepts both singular and array requests should be with respect to its return type.
For example, let's say hypothetically, the
queryRecords
interface accepts either a string or an array of strings as itsqueryTexts
property.Describe the proposed solution
I would argue that for someone working with the client, it's more convenient to unwrap the arrays. Given a singular string request, it's not possible for there to be more than one entry in each of the arrays so we can save the client the unnecessary boiler plate of extracting the 0th element. The principle here is that the client matches the shape of the supplied argument. So the shape of the response would be:
I'm not proposing we always unwrap responses that have a single element in them though. For example, if the caller supplied us with an array that had a single element in it, I think that the right behavior is the behavior below:
Again, the principle here being that we're matching the shape of the supplied query. Since the caller provided us with an array, we return them an array of responses, even though there's only a single element.
Alternatives considered
The alternative here is to do what we do today which would be:
The benefit of this approach is that the shape of the response is always consistent with itself. That said, I would argue that consistency between the input and the output of the function is more important than consistency across calls to a function.
Importance
nice to have
Additional Information
No response
The text was updated successfully, but these errors were encountered: