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

About Sequence. #49

Closed
back2dos opened this issue Feb 13, 2017 · 2 comments · May be fixed by haxetink/tink_pure#1
Closed

About Sequence. #49

back2dos opened this issue Feb 13, 2017 · 2 comments · May be fixed by haxetink/tink_pure#1
Assignees

Comments

@back2dos
Copy link
Member

So I've merged it for now. I wonder though, what exactly is the purpose of it?

Is it mostly to just say "one or many"? Or do we want immutability? Does it really make sense to allow for array access? Wouldn't it potentially be better to have a more opaque implementation that could potentially be lazy, so that e.g. seq.filter(...).slice(x, y).map(...).filter(...).map(...) really just constructs one sequence, and it only does it when the iterator on said sequence is created?

I'm just throwing around ideas. Maybe you could share your experience about how you've been using this @kevinresol ?

@kevinresol
Copy link
Member

Yeah I use it as immutable data mostly, and a shorthand or method overload for accepting a single item.
But recently I realized that there is tink_pure which I didn't know before. Maybe that would be a better place?

seq.filter(...).slice(x, y).map(...).filter(...).map(...) really just constructs one sequence, and it only does it when the iterator on said sequence is created?

Yeah, that sounds good. You usually have better ideas 😄

@kevinresol
Copy link
Member

Let's continue this at haxetink/tink_pure#1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants