Dan writes:

>Would you (or anyone else here -- volunteers?) be willing to examine the
>senders
>and change those that need it to rangeIncludes: before we do this?

Gosh, you guys work fast.  I'd be happy to look at some classes for calls
to interval includes:, if they haven't all been inspected already.  But I
don't want to re-do work that's already been done.

>I think the proper fix for the range interpretation is to replace the calls
>that expect a range interpretation with, say, #rangeIncludes: or some better
>choice that you might recommend.

I think that a better fix might be to introduce a new class that represents
a range, which no step size expressed or implied, but with the ability to
be open or closed at each end.  Something like

	x := Range closed: 3 closed: 7   => [ 3 .. 7 ]
	y := Range open: 4 closed: 9     => ( 4 .. 9 ]
	z := Range closed: 4 open: 2     => the empty range
	x join: y			 => [ 3 .. 9 ]
	x meet: y			 => ( 4 .. 7 ]

This sounds like an interesting student project, but I think it would be
worth doing only if there is actually a use for it.   Ranges aren't
collections (well, maybe they are infinite collections of reals?) and they
aren't magnitudes (because they are only a partial order).

Would classes like these actually be useful in the graphic methods?  My
assumption was that the new method for  interval|includes: had been written
to speed up some code in  the windowing system, since without it
interval|includes: uses the method in Collection which actually runs the do:

	Andrew