generated from snivilised/astrolib
-
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
rx: change Range operator to be able work with native instances of Item[T] #232
Closed
Tracked by
#122
Labels
feature
New feature or request
Comments
we need to change the any specification on all generic types to a custom interface which contains no methods. And going forward, we need to avoid using any as a constraint for generic parameters. The reason for this is that if we need to modify the characteristics of a generic parameter, it is difficult to do safely, requiring a global search and replace, rather than just modifying the custom interface. type AnyOb interface {} |
plastikfan
added a commit
that referenced
this issue
Apr 20, 2024
plastikfan
added a commit
that referenced
this issue
Apr 20, 2024
plastikfan
added a commit
that referenced
this issue
Apr 20, 2024
plastikfan
added a commit
that referenced
this issue
Apr 20, 2024
plastikfan
added a commit
that referenced
this issue
Apr 24, 2024
plastikfan
added a commit
that referenced
this issue
Apr 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the Range operator generates a sequence of items based off the numeric index of a range iteration. This is forcing other operators that it can be combined with to also become Num based. This is too restricting. Instead, we need to allow the client to control the type of the index, so it does't just have to be Num based. Instead of being implemented as a loop like:
the for range loop need to get the start, condition and incrementor from the client. This will enable the index variable to be of any type T, instead of being forced to be Num based.
We could have a new range operator, let's say RangeV which creates an alternative T based iterable range. This will allow alterntive types, eg a float, or even an object.
So the loop would something like:
In this implementation, start, until and inc are defined by the client and are based on Item[T].V. We can can create an Arranger type which defines these methods to be implemented by client. We can also provide a comparable arranger, so that the client doesn't have to manually implement this for scalar types.
The text was updated successfully, but these errors were encountered: