-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: use type-specific methods in public clients, Value in internal clients #90
Conversation
lib/src/internal/utils/utils.dart
Outdated
import 'package:momento/momento.dart'; | ||
import 'package:momento/src/errors/errors.dart'; | ||
|
||
Value getStringOrBinaryFromDynamic(dynamic value, String parameterName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a really cool thing to try!
I'm guessing the editor isn't able to give any type hints for this at all though? and it would be a runtime error if you just tried to pass in like, some random object type as the argument to one of these dynamic args? If so, lemme noodle on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If type hints are a good trade for an uglier API, we could add the type to the function name like we do with some of the collection methods in Java: dictionarySetFieldsStringBytes
.
In my reading about Dart, I see that:
I believe our options are then:
I see the strong typing is one of Dart's selling points, and I do not have an intuition as to how kosher it is to use
Are there any official statements on the matter? These two GitHub issue threads show a lot of folks are unsatisfied about this: Show no sign of quick resolution and that JSON parsing is an exemplar of the problem and a sore point for devs. I am leaning toward using extension methods or the mangled function names. |
…ublic clients instead of using dynamic
lib/src/cache_client.dart
Outdated
Future<GetResponse> get(String cacheName, String key); | ||
|
||
Future<SetResponse> set(String cacheName, Value key, Value value, | ||
Future<SetResponse> set(String cacheName, String key, String value, | ||
{Duration? ttl}); | ||
|
||
Future<DeleteResponse> delete(String cacheName, Value key); | ||
Future<SetResponse> setBinary(String cacheName, String key, List<int> value, | ||
{Duration? ttl}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
opted to allow only String keys, but can provide options for allowing binary keys too if preferable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems like a good compromise to me.
The only suggestion I might throw out there is to consider doing a find-and-replace on the word Binary
with the word Bytes
, I think that might be a little more clear and a little more consistent with naming in other SDKs, but I don't feel strongly about it and am fine shipping like this if you or others prefer Binary
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addresses #69
First approach: Allows users to pass String and Binary (List) arguments to functions directly by using the
dynamic
type, while converting to StringValue or BinaryValue internally.After discussion, we settled on creating public-facing methods that accept String keys and String/Binary values, but internal clients still use Value as a way to create a type union of the two