Thanks Simon. I just looked through what you have. You gave
me a few ideas. But, here are a few things I don't like:
* for efficiency I would like the ability to read/write
multiple elements at a time. I want the API to have a superset
of the features in IO if possible.
* instead of calling has_next? I'm just having next return nil
or an empty string/array (for getting N elements). If the
collection can have nil elements, you'll have to ask for N
elements (could be 1) so that you get an empty array at the
end.
* no standard insert/delete operations. I don't need them now,
but they might be useful to others.
* like the C++ iterator, yours standardizes on
allowing/creating/comparing multiple iterators on the same data
structure. I don't want to do this because many sequential
data structures can't handle this. The primary example would
be an IO (especially a non-file) which only allows you to
read/write at one location at a time. Another would be a text
editor buffer where you can only insert/delete at the cursor
position. Instead of allowing multiple iterators for a data
structure, you'll be able to get and set the position where
"position" is an object that you might be able to compare
and/or do arithmetic on (depends on the data structure).
I think I'll call the class I'm doing "Cursor" because it most
resembles what you can do at the cursor in a text editor and
I've also seen the term "cursor" used for external iterator.
I might take some of the ideas in your Iterator classes also
(some from C++ STL iterator it looks like), if you don't mind.
Eric
···
--- Simon Strandgaard <neoneye@gmail.com> wrote:
On 4/28/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:
> I've read a few discussions/comparisons between enumerators
> (internal iterators) vs. cursors (external iterators).
From
> what I gather those discussions in favor of enumerators
assume
> the application is a simple single pass read-only
processing of
> all/some of the elements in a collection. You do this a
lot
> with a collection and I like enumerators best for doing it.
> But when you are doing something more complex, enumerators
> don't cut it.
[snip]
Thanks Simon. I just looked through what you have. You gave
me a few ideas. But, here are a few things I don't like:
* for efficiency I would like the ability to read/write
multiple elements at a time. I want the API to have a superset
of the features in IO if possible.
True, I didn't made mine for speed.
* instead of calling has_next? I'm just having next return nil
or an empty string/array (for getting N elements). If the
collection can have nil elements, you'll have to ask for N
elements (could be 1) so that you get an empty array at the
end.
What if you are iterating through an array that coincidentially
contains a nil.. like this [42, nil, 42] ?
* no standard insert/delete operations. I don't need them now,
but they might be useful to others.
Yeah, I don't have neither insert nor delete.
I didn't needed it when I made the lib. I though about it,
but couldn't decide how to approach this problem.
* like the C++ iterator, yours standardizes on
allowing/creating/comparing multiple iterators on the same data
structure. I don't want to do this because many sequential
data structures can't handle this. The primary example would
be an IO (especially a non-file) which only allows you to
read/write at one location at a time. Another would be a text
editor buffer where you can only insert/delete at the cursor
position. Instead of allowing multiple iterators for a data
structure, you'll be able to get and set the position where
"position" is an object that you might be able to compare
and/or do arithmetic on (depends on the data structure).
This sounds interesting. I would be interesting at looking
at how you would approach this.
I think I'll call the class I'm doing "Cursor" because it most
resembles what you can do at the cursor in a text editor and
I've also seen the term "cursor" used for external iterator.
I might take some of the ideas in your Iterator classes also
(some from C++ STL iterator it looks like), if you don't mind.
Feel free to use all of it as you like.
Is your project on rubyforge ?
···
On 4/28/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote: