On Mon, Nov 11, 2002 at 09:49:35PM -0800, Dave Whipp wrote:
: This get back to defining the focus/level of the testing that we want to 
: achieve. Some of these items may make sense for paranoid testing; but 
: not as part of a comprehensive test suite.

Er, I thought it was paranoia that makes a test suite comprehensive... :-)

: Consider item 0. Do we need to test C<reverse(undef)>? The answer is 
: probably "no": conversion of undef to an empty lsit is a property of the 
:  list context in the caller. We tested that as part of our compehensive 
: set of arglist evaluations. The reverse function never sees the undef, 
: so we don't need to test it.

Just as a nitpick, reverse(undef) does not produce a null list.  An undef
in list context is still a scalar value.

: Item 1 may be worth testing; but then we see that what we realy have is 
: a parameterised test: one control path with multiple datasets. One 
: parametarised test would code most of the other items.
: 
: The most interesting case is Item:2. This is a question that a user 
: might want to ask. The question is a language-issue, not implementation. 
:  Derivative thoughts ask about lazy lists in general (is the reverse 
: still lazy?); and hence onto tied lists. Perhaps there is an interface 
: to list-like objects: perhaps we need to document/test that.

I think a major point that everyone's missing here is that there
may well no longer be a single global &*reverse function anymore,
or if there is, it'll defer the actual reversing of list elements to
the list object in question, just as &*print defers to the object's
stringification and/or print methods.  So a reverse on a lazy list
may or may not work, depending on whether the lazy list object knows
how to reverse itself.  So in

    reverse 1,2,3..Inf

(3..Inf).reverse may choose to fail, or it may choose to return

    Inf,Inf,Inf,Inf,Inf...

ad nauseum.

It will be a pervasive problem to decide whether to organize these
tests from the viewpoint of the underlying class or the overlying
user view.  My guess is we end up doing both, because both views
need to work.

Larry

Reply via email to