Stephan Rudlof wrote:

>Nevin Pratt wrote:
>  
>
>>The final draft of the ANSI standard (and presumably the actual 
>>standard) specifies that if the argument to #add: for Set is nil, the 
>>results are undefined.
>>
>>VisualWorks for this case just returns nil, and otherwise does nothing.
>>Squeak throws an exception.
>>    
>>
>
>Raising an exception seems to be correct here: it says to you: 'Hey,
>something has gone wrong here!'
>  
>

Just playing the devil's advocate here...

Why is 'aSet add: nil' wrong (that is, why should it be considered to be 
an erroneous message send)?

For any method, there are only three possibilities for indicating a 
problem: (1) return nil, (2) return some other specialized error return 
value, or (3) throw an exception.  We also know that pattern #1 
(returning nil) is used quite often by class designers (including the 
'Set' designers of most Smalltalks, but not Squeak).  This means that it 
is not uncommon at all for a method call to return nil (such as 'aSet 
add: nil' returning nil for other Smalltalks).

To argue which of the three patterns is "more" appropriate has been a 
subject of debate for decades now.  My personal take on which is "more" 
appropriate is: it just depends.  In other words, you can't make 
sweeping generalities about it, but each situation needs to be weighed 
in it's own context.

Now, in the case of 'aSet add: nil', I personally think pattern #1 is 
appropriate.  I think pattern #3 would have been OK, and indeed, 
intellectually I am quite ambivalent toward it.  However, the thing that 
finally sways me over to pattern #1 for this case is simple: it appears 
to be what has been done by everybody else all along anyway.  Being 
"different" seems gratuitous in this case.

(As to the other times when pattern #1 is preferable over pattern #3, 
those cases would fall into "Do The Simplest Thing That Could Possibly 
Work" category)

>  
>
>>GLORP appears to depend upon the VisualWorks behavior.
>>    
>>
>Why does GLORP adding nil to a Set and expecting it to silently do nothing?
>
>  
>

GLORP is highly reflective, and it is just passing in as the argument 
what was returned from another message.  And, the other message used 
pattern #1.  Consequently the set gets a nil argument.

To change this behavior in GLORP would require adding a bunch of 'isNil 
ifTrue:ifFalse:' checks into the code in a bunch of places, when it 
otherwise wouldn't be necessary.

>>Since GLORP has 
>>been ported to VA and Dolphin, I'm guessing that they also have VW's 
>>behavior.  Thus, Squeak appears to be the odd-man out.
>>
>>I personally am not a fan of exceptions, and use them very sparingly, if 
>>at all.  And in this case, I personally prefer VW's behavior.
>>    
>>
>
>You can't rely on a behavior, which is defined as 'undefined'.
>

Hmm, that's actually a pretty convincing argument for arguing that GLORP 
needs to be changed.

Well, either that, or arguing that the ANSI standard should be changed :-)

Nevin