Language unique library features/changes #3153
Unanswered
thecoolwinter
asked this question in
Feature Requests
Replies: 1 comment 1 reply
-
Disclaimer: I haven't written a line of Swift and I'm not familiar with the Storage stuff.
I opined on this here a while back - I'm open to the idea. But your statement sounded conflicting to me:
In that case, wouldn't you just init the object once and keep that alive? Do you have a use case for mutating an initialized client's headers/URL/etc.? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Languages often have different requirements or use cases depending on where they’re being built, and how objects are used in that language. I’m curious, is it okay for client libaries to make slight changes to the API or implementation of a client?
Specifically, something like this PR: supabase-community/storage-swift#1
In this case, swift devs often keeps objects alive for the entirety of an app’s lifecycle. Having to re-init an object with new headers could cause memory leaks and unexpected behavior. But implementing a config object, or even public config variables, splits from the precedent set by the JS and Dart libraries.
Should this kind of change be okay? And I guess my suggestion would be: Can the client libraries follow the JS and Dart libraries as close as possible, but in the case where a change is necessary, keep API’s the same across the language?
Beta Was this translation helpful? Give feedback.
All reactions