couple of really noob questions (ranges, toString)

spir denis.spir at gmail.com
Mon Nov 1 18:05:19 PDT 2010


On Mon, 1 Nov 2010 20:02:14 +0000 (UTC)
Michael Woods <alienhunter3 at gmail.com> 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



More information about the Digitalmars-d-learn mailing list