| |
 | Posted by Jonathan M Davis |  Permalink Reply |
|
Jonathan M Davis 
| On Tuesday, November 02, 2010 04:16:58 spir wrote:
> On Mon, 1 Nov 2010 20:40:30 -0700
>
> Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > The term "pop" does _not_ mean that an element is returned but that it is removed from the range. This is true for pretty much anything that uses a pop function in any language - stacks, lists, etc. It _is_ true that many implementations choose to have pop return the element which is popped, but that's an implementation detail. The term pop merely indicates that an element is removed from an end of a range or container.
>
> All right, that's where I went wrong. Thank you for the clear explanation. (Now, I will continue with the article by Andrei Alexandrescu, 10 pages left :-)
>
> [But I do not know of any pop not returning the removed value in any lang or library; instead, pop is the favorite example of people arguing against the distinction between actual functions (result, but no effect) and actions (effect, but no result): naughty pop does both. Maybe call it here remove()? Even if "pop"'s sense was defined by an all-mighty authority, we could hardly avoid people having different expectations born from previous experience, esp when it's so widespread: the two pop examples at http://en.wikipedia.org/wiki/Stack_%28data_structure%29 return the element.]
C++'s pop functions don't return anything either, but it is true that many libraries in many languages choose to have pop functions return the value which is being popped. Having popFront() return a value in addition to having front look at the first value in the range wouldn't necessarily be a problem, but it isn't strictly speaking necessary. In some languages (certainly C++, though I'm not sure about D), returning a value which isn't used can mean a wasted copy or object construction which can be inefficient (particularly when dealing with large objects on the stack). Whether a pop function returns anything tends to depend on how much an efficiency concern the library writer thinks that it is and how likely they think that it is that the popped value is going to be wanted. If it's expected that someone will always want the popped value, then it can be quite nice to have the pop function return it, but if there's a good chance that they won't, then it could be an unwanted inefficiency. It all depends on the goals and concerns of the library writer. In this case, D chose to not have popFront() return anything.
> I would also find current() much clearer than front(), since from the
> client's perspective it looks like shrinking the collection (or view)
> instead of traversing it; see the confusion expressed by the OP's original
> question; but well...
Except that unlike an iterator (which indicates a single element), a range
indicates a range of elements, so it can have both a front and a back (similar
to having two iterators indicate a range of elements), so current() would be
highly confusing once you went beyond input or forward ranges. For instance, bi-
directional ranges have back and popBack(), and random-access ranges have the
subscript/slicing operator which can access an element or range of elements in
the range, so current() would become highly confusing. What you have is a range
of elements which has a clear first element (and assuming it isn't infinite or of
indefinite length) a clear last element. So, front and back access them and
popFront() and popBack() pop them. It is indeed generally a view of a collection
of elements, but there is a definite order to them, whereas current() does not
indicate order.
- Jonathan M Davis
|
