[std-interval] Re: Std-interval Digest, Vol 3, Issue 1

[Alan Eliasen]

first.i.last at comcast.net wrote:
>>but we agree that is not correct for intervals.  Whole is probably
>>the best we can do.
> 
> Yuck.  Empty is clearly superior to whole in that it has less 
> chance of accidentally producing apparently sensible results.
> And for production an uninitialized interval should not be
> initialized.  After all,  C++ lacks basis support for array
> initialization so any default initialization effort, like touching
> every value in a big array, is just wasted time.

   I think that there should *never* be a zero-arg default constructor
for intervals.  All constructors should have at least one argument to
force the programmer to declare their intent.  There's no point to a
zero-argument constructor, because allowing such gives the programmer
*lots* of ways to mess up and use uninitialized objects.  If you want to
use an interval, you should provide reasonable arguments to it in a
constructor.  That way, you *never* get an Interval object that hasn't
been initialized to a known value.  A huge class of errors is eliminated
at compile-time!

   In my interval implementations in Java, there's no way to construct
an interval without specifying its values.  There's no reason to allow a
"default" interval.  I believe in constructing APIs that eliminate
sources of expected programmer error at compile-time.  This is an
obvious case.

   There is simply no reason to allow a "default" interval initialized
to a value that we *know* isn't right for anything.  We can prevent this
mess at compile time, and should.

-- 
  Alan Eliasen                 |  "When trouble is solved before it
  eliasen at mindspring.com       |    forms, who calls that clever?"
  http://futureboy.us/         |              --Sun Tzu