couple of really noob questions (ranges, toString)
Jonathan M Davis
jmdavisProg at gmx.com
Mon Nov 1 18:47:38 PDT 2010
On Monday 01 November 2010 18:05:19 spir wrote:
> 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
> > 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).
The best place to start learning about ranges is probably here:
front, popFront(), and empty make perfect sense as they are and work quite well.
hasNext() and next() have the serious drawback of mixing iterating through the
range and getting an element in it. It's one of the serious flaws in Java's
iterators. It's far better to have getting the current or front element be
separate from moving or popping the next one.
In any case, you can use ranges in a manner similar to lisp's slists, but
they're definitely more flexible than that, since they're an abstraction rather
than a container. And ultimately, there isn't really anything functional about
them. They just allow for you to use them in a manner similar to slists which
are heavily used in functional languages.
Ranges are extremely powerful and generally are _way_ better than iterators
(though there are a few cases where they become more awkward than iterators).
- Jonathan M Davis
More information about the Digitalmars-d-learn