Set>>add:

Stephan Rudlof sr at evolgo.de
Mon Nov 11 11:28:19 UTC 2002


Nevin Pratt wrote:
> 
> 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.

This has been my reason for ...


>>>
>>>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!'
>> 
>>

this,



> 
> 
> Just playing the devil's advocate here...
> 


in your words:

> 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.

Exactly.

I tend to follow ANSI if in doubt (and just use something what is guaranteed
to work by it)
   *** for an app with the design goal to be portable ***
what Glorp seems to be.

In other words: I don't like to change to non ANSI behavior to satisfy
applications thought to be portable.

Moreover: changing to non ANSI behavior could *break* other apps, which
*are* portable already!

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

I think this could open another can of worms ;-)


Greetings,

Stephan

> 
> Nevin
> 
> 
> 
> 


-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3




More information about the Squeak-dev mailing list