On Friday, 28 March 2014 at 23:14:56 UTC, Tobias Müller wrote:
On Thursday, 27 March 2014 at 20:49:16 UTC, Walter Bright wrote:
On 3/27/2014 12:21 PM, Rainer Schuetze wrote:
This loop is intuitive. Not being allowed to call empty or
front multiple times
or not at all is unintuitive. They should not be named as if
they are properties
then.
I can concede that. But I can't concede being able to call
front without first calling empty, or calling popFront without
calling empty and front, or requiring 'pump priming' in the
constructor.
Disclaimer: I'm a C++ programmer just lurking here, I've never
actually used D.
I find it very counter-intuitive that 'empty' is required before
front or popFront.
Since 'pump priming' in the constructor isn't wanted either, i'd
suggest the following protocol:
while (popFront())
{
front;
}
popFront is then required to return !empty.
'empty' as a separate property getter can stay but is not
required for the protocol.
This way, it's clear that the work to fetch the next element is
always done in popFront.
Generally I find dependecies between functions problematic that
require a specific call sequence. If they can be removed, they
should.
With my proposed solution, there's still one minor dependency,
namely that front is not valid before the first popFront. This
could be solved by again combining the two, as proposed by
someone else in this thread.
Tobi
First sorry for my english.
I agree.
All work is done in "bool popFront()" (well, this name may no
longer be the most appropriate).
In this function the first / next item is obtained and caches.
Returns true if any element, false otherwise.
"front" return de cached element as now, as many times as desired
and without side effects.
"empty" function is no longer necessary, but it might be useful
to keep changing the return type for example to int:
1 - Sure there is more elements
0 - Sure there is NO more elements
-1 - I don't known. Try popFront to know if more element
Of course this function as "front", without side effects
