2
Language unique library features/changes
Source: supabase/supabase#3153 · opened by @thecoolwinter
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:
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?
Specifically, something like this PR:
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?
No pledges yet. Be the first to back this.
Comments
Similar requests
Enable email Llanguage change based on frontend language
2 votes · 0 comments
Client Libraries
16 votes · 0 comments
Request: Internationalization for Authentication Email Templates
58 votes · 0 comments
Skip support
4 votes · 0 comments
Publish "etl-core" as separate library on crates.io
1 vote · 0 comments
No comments yet.