-
Notifications
You must be signed in to change notification settings - Fork 6
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
Call for feedback on API design #20
Comments
One thought: When using Static Type Checks, the type can also be omitted / inferred. For example, the following two lines should work without explicitly specifying the type:
when date.add<DateLike>({ days: 1 }); would require implementing my suggestion in #2 (comment), so date.add({ days: 1 }); which cannot be inferred, would fall back to |
Ah, I misunderstood your earlier comment. In which case option 1 becomes:
Thats not a bad option. However, the |
@dcodeIO how likely is it that you would implement type parameter defaults? |
I see a need for it, and seems unproblematic (haven't investigated in detail, though), so I'd say it's likely. Just can't say when :) |
I'm happy to play the long game - in which case option (1) is the clear winner :-) |
Based on the current implementation progress, the
PlainDate
andPlainDateTime
types are now relatively complete. These should be useful for anyone wanting to perform non-timezone aware date and time manipulation.Before making a v1.0 release I am keen to stabilise the API. The biggest challenge here is dealing with union types. For example, the first arg of the
PlainDate.add
method unions three different types:This allowing you to do the following:
Unfortunately AssemblyScript doesn't support union types so we need to use a different technique here.
There are a few options this library could employ:
1. Static Type Checks
Use a generic type then perform static type checks to determine the type.
Unfortunately the compiler requires type information, which must be provided as follows:
2. Create multiple API methods
This method could be split into three, with the one that is considered the most frequently used given the plain
add
form:What do people prefer? Any other ideas?
The text was updated successfully, but these errors were encountered: