[squeak-dev] Re: intersect: when intsersects: is false
frank.shearar at angband.za.org
Mon Jun 21 19:02:29 UTC 2010
On 2010/06/21 16:03, Louis LaBrunda wrote:
>>>> One could just
>>>> leave it as it is, because the precondition for answering a "correct"
>>>> rectangle is that the receiver and the argument intersect. If they don't, the
>>>> answer is undefined, which means that whatever is answered is correct in a
>>>> mathematical sense.
>>> I urge some caution here. If "whatever is answered is correct in a
>>> mathematical sense" is true then returning any rectangle like (100 at 100)
>>> corner: (150 at 150) would be correct, clearly that is not the case. In
>>> Smalltalk, nil is undefined, nil is probably the "correct" answer.
>> Yes, this is tempting.
>> However from a pragmatic point of view that would mean that:
>> - either every call must be protected with an intersects: test or (...
>> intersect ...) ifNil: [...]
>> - or UndefinedObject must understand Rectangle protocol
>> Answering an empty rectangle seems more simple with this respect.
> As I don't play with rectangles much, I will defer to your better judgment.
> Mostly I was concerned about the "whatever is answered is correct in a
> mathematical sense" statement but maybe I was being too picky. And why I
> quoted "correct" when I said nil was probably the "correct" answer. Correct
> or not an empty rectangle is probably the "better" answer.
It does occur to me that perhaps the behaviour's deliberate. Reading
Andreas' comment in the method, it's an optimisation of a method that
goes back to Smalltalk-76 !
GNU Smalltalk defines the behaviour of #intersect:  as returning nil
for non-overlapping Rectangles . (So we're already incompatible with
another dialect!) My brief Googling didn't reveal what the other
More information about the Squeak-dev