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

Provide a char_range method on Rope #13

Open
gchp opened this issue Feb 2, 2016 · 4 comments
Open

Provide a char_range method on Rope #13

gchp opened this issue Feb 2, 2016 · 4 comments

Comments

@gchp
Copy link
Contributor

gchp commented Feb 2, 2016

Rope provides chars method which gives an iterator over all the chars in the Rope. This is great, but I find myself creating an iterator over all the data when I only really need a small subset.

Being able to get an iterator over a subset of the entire dataset would be great. I envision it something like:

// get the first 5 chars from the rope
let chars = rope.char_range(0..4);
// get chars from the 11th character to the end of the rope
let chars = rope.char_range(10..); 

I am putting together an implementation of this now, but wanted your thoughts first to make sure it's something you see value in having.

@gchp
Copy link
Contributor Author

gchp commented Feb 2, 2016

This is also what prompted me to submit #12 - I figured it would be best to implement it once, rather than in two places.

@gchp
Copy link
Contributor Author

gchp commented Feb 2, 2016

An alternative to this would be to implment iterators for RopeSlice. That would mean I could do:

let chars = rope.slice(10..20);
for ch in chars { ... }

@nrc
Copy link
Member

nrc commented Feb 3, 2016

Seems like a good thing to add. However, it's worth thinking about the bytes vs chars distinction - the slice approach would be bytes bases. For char_range, you'd have to iterate over the characters before the ranges in any case, so it doesn't seem a huge win over just getting the char iterator. If getting a slice of the rope by bytes is Ok for you, then that is probably a better solution.

@gchp
Copy link
Contributor Author

gchp commented Feb 3, 2016

That's a good point. I went with the bytes approach. Take a look at #14 and let me know what you think.

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

No branches or pull requests

2 participants