[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Stepper protocol



Date: Wed, 25 Oct 89 11:33:11 PDT
   From: heh (Hugh Hoover)

   re: the step protocol.

   How about this nice message?

   while (tableStepper->hasValue()) {
     porphyria(tableStepper->stepValue())
   }

I keep trying to pronounce 'porphyria' :-)

   Where stepValue() steps and returns the value of the iterand (either
   pre or post-increment - must have default).

It would have to be post-increment.  See my reply to Ravi's message.

   The only reason is to slightly tighten up loops, because you will almost
   always have to have both step() and value().  The downside is that it is
   NOT obvious whether stepValue() is pre or post increment, so it could 
   confuse a lot of developers (like me).

I don't think it's worth the expense.  In my uses of it, I
deliberately separated value-access from stepping.  The separation
caused a surprising conceptual cimplification.  I didn't worry about
retrieving the value more than once.  I could one less thing in my
head at a time.  It was more familiar from classical loop programming.
And it separated side-effect free actions (value) from side-affecting
ones (step).

   Another thought is to have some messages for using multiple steppers, esp,
   termination condition checking.
   so maybe hasValueAnd(otherStepper->hasValue()) or something.  This could
   help reduce long sequences of blah->hasValue && blue->hasValue() ...

Oh boy!
1) hasValueAnd enlarges the protocol but not the functionality.
2) using && is obvious and easy for both writing and reading
3) hasValueAnd requires extraneous, obscuring punctuation.
4) using && generalizes to other control structures.
5) compilers optimize &&, especially when hasValue is inline.
6) && looks more like conditional loop expressions.
7) MultiSteppers are even cleaner if we need simplification.
8) Finally, note the expression length:

	stepper->hasValueAnd(otherStepper->hasValue())
	stepper->hasValue() && otherStepper->hasValue()

Sorry!  This was just too much fun to pass up!  Most of the concept
juggling is os much a matter of hard tradeoffs that this was a welcome
break.

dean