On 2010/06/21 16:03, Louis LaBrunda wrote:
>>>> snip...
>>>> 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.
>>>> snip...
>>>
>>> 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.
>> Nicolas
>
> 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 [1]!

GNU Smalltalk defines the behaviour of #intersect: [1] as returning nil 
for non-overlapping Rectangles [2]. (So we're already incompatible with 
another dialect!) My brief Googling didn't reveal what the other 
Smalltalks do.

frank

[1] 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.2641&rep=rep1&type=pdf

[2] 
http://www.gnu.org/software/smalltalk/manual-base/html_node/Rectangle_002drectangle-functions.html