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
|