On Mon, 1 Nov 2010 20:02:14 +0000 (UTC)
Michael Woods <[email protected]> wrote:
> I guess that I'm asking if write() calls an object's toString method
Exactly.
> Question 2:
>
> This is more a broad request for clarification, than a specific question.
> I'm trying to understand the range interfaces. I'm trying to make this
> linkedList class implement the InputRange interface (among others). I'm
> pretty sure that I've got opApply, opIndex, and opSlice figured out, but I
> can't
> for the life of me figure out exactly what front(), popFront(), and empty()
> are supposed to be doing. (I realize that the opX functions aren't part of
> the
> InputRange interface.) Is popFront supposed to delete the actual front
> element from the list? Or is it supposed to represent some kind of internal
> pointer that is there solely for the purpose of range functionality? If the
> latter, how should the pointer get reset after it has gotten to the end once?
> Should the pointer even need to be reset, or is popFront supposed to only
> cycle through once during the entire lifetime of the range object?
I'm not 100% sure because I'm also a D noob, rather projecting knowledge from
other PLs -- so take my words with precaution. [Please, D gurus, tell if what
follows is ok.]
If I'm right, the point of ranges is to offer kinds of particular views on all,
a part, or an aspect of a collection; without having to create a separate
collection just for that. Typical use is for traversal (iteration). Since you
know python, its iterators (and generators) are kinds of ranges. Eg you can
write an iterator to traverse a list in reverse order, or every third element
-- without creating new lists for that. You can also make an iterator or
generator on a "virtual list", eg generating squares of ints in a given range.
front(), popFront(), and empty() together form a way to implement a sequential
iterator on a collection. [But I must admit it really does not fit my POV on
the topic -- this trio strongly smells functional :-) and actually basically
models a linked list -- I'm certain its designer has a heavy Lisp baggage! I
would rather have a hasNext() and next() duo.]
Now, their working is simply to allow moving across elements, so no popFront()
does not pop. Examples:
routine dynarray list
popFront inc(ptr) current = current.next
front() *ptr current.element (possibly dereferenced)
empty() length == 0 length == 0 (maintained as field)
On a "true" linked list where every node implements the properties & methods of
a list, then popFront is returning the second node, meaning the head of the
rest: l = l.next.
Hope most of this is correct (critics welcome).
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
