On Thu, 22 Jul 2010 16:13:21 -0400, Walter Bright
<[email protected]> wrote:
Steven Schveighoffer wrote:
The algorithm is the one doing the requiring, not the container. So,
if there are standard algorithms some of which require ranges and
others that require interfaces, the container implementor is obliged
to provide both.
Now you are just misinterpreting :) Nobody said anything about D
interfaces.
I meant iterators, not interfaces. Sorry for the confusion.
OK, sorry for my confusion :) The unquoted message that you responded to
made me think you intended to type interfaces was:
"There aren't two competing interfaces here. If your interface
requires a range of elements, you use a range. If it only needs a
single element, you use a cursor."
From my experience with dcollections, implementing cursors in addition to
ranges is very trivial. Most node-based container types use "iterators",
or pointers to elements underneath ranges anyways. It's generally not an
extra effort to expose them correctly. I think cursors solve the safety
issue quite well.
If you are using duck typing instead of interfaces, it's even easier,
since you can cover both ranges and cursors with one function (you can
make a range out of a cursor, or a pair of cursors from a range very
easily, and then call your implemented function).
Dcollections has a feature where you can swap the underlying
implementation for something completely different. The interface between
the container class and the implementation is some sort of iterator-like
idiom. I plan to homogenize this, and make it better documented.
Hopefully it will become much easier to swap implementations in the future.
-Steve
