Skip to content
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
plastikfan opened this issue Apr 17, 2024 · 1 comment · Fixed by #236
Closed
Tracked by #122

rx: change Range operator to be able work with native instances of Item[T] #232

plastikfan opened this issue Apr 17, 2024 · 1 comment · Fixed by #236
Assignees
Labels
feature New feature or request

Comments

@plastikfan
Copy link
Contributor

plastikfan commented Apr 17, 2024

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:

		for idx := i.start; idx <= i.start+i.count-1; idx++ {
			// ...
		}

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:

		for idx := i.start(); i.until(idx); i.inc(&idx) {
			// ...
		}

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.

@plastikfan plastikfan mentioned this issue Apr 17, 2024
59 tasks
@plastikfan plastikfan self-assigned this Apr 17, 2024
@plastikfan plastikfan added the feature New feature or request label Apr 17, 2024
@plastikfan
Copy link
Contributor Author

plastikfan commented Apr 19, 2024

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 24, 2024
feat(rx): add WithCalc (#232)

feat(rx): add range iterator (#232)

feat(rx): rename HasItems to ContainItems (#232)

feat(rx): continue range iterator (#232)

feat(rx): fix copy by ptr range iterator (#232)
@plastikfan plastikfan linked a pull request Apr 24, 2024 that will close this issue
plastikfan added a commit that referenced this issue Apr 24, 2024
feat(rx): add WithCalc (#232)

feat(rx): add range iterator (#232)

feat(rx): rename HasItems to ContainItems (#232)

feat(rx): continue range iterator (#232)

feat(rx): fix copy by ptr range iterator (#232)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant