This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: ifNil: better named whenNil:
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
In ifNil: isOK ifTrue: Vassili, makes a case for the fact that the #ifNil: methods return the receiver if the receiver is not nil. He provides three arguments:
All other Smalltalks already do it that way. Tough to argue with that -- ask any parent.
#at:ifAbsent: and #detect:ifNone: do it that way. This argument fails because both have a primary clause of at: or detect:. The alternative clause of ifAbsent: or ifNone: is to be taken only when the primary fails. The value returned by the primary clause is clearly to be used when the primary succeeds.
Further, there is no sense that #at:ifAbsent: and #detect:ifNone: belong to the controlling protocol, as are the #ifNil: and #ifTrue: methods. In fact, they are in the accessing and enumerating protocols, respectively.
#ifNil: should actually be seen as a value alternation method rather than as a control alternation method. Fine, then it just has a bad name. Perhaps #whenNil: would have been better, especially if it were in the accessing protocol. Naming things is always a tough business, with many trade-offs: functionality, linguistic redundancy, consistency, and readability -- as well as writability.
It's tempting to argue there should be some super language guru to decide such things -- a standards group, perhaps -- but that would go against the fundamental freedom that Smalltalk provides for innovation. Still, there should be some way for the entire Smalltalk community to propose, deliberate and decide how the language should evolve.
Previous Topic
