This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Re: ifNil: better named whenNil: Feed Title: Michael Lucas-Smith Feed URL: http://www.michaellucassmith.com/site.atom Feed Description: Smalltalk and my misinterpretations of life Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Michael Lucas-Smith

After reading Vassili's discussion on ifNil: and now Rich's discussion on ifNil: I think I'd have to say that I agree with Rich.

I am the guilty party here. I started this conversation when complaining that the UI Painter creates ugly aspect methods. I brought up my use of ifNil: in all my lazily initialised methods.

At first I didn't quite get what Vassili and Rich were talking about, but after reading for a little longer it drawned on me that ifNil: does not suggest it will always return a non-nil value. whenNil: makes a lot more sense!

As a result, however unlikely this seems, I'd also like to help push this idea of "a place where the smalltalk community can discuss and vote on issues such as this to further evolve the language".

Whether a particular dialect evolves with the recommendations made by this body/website/group/community doesn't matter. There are some smalltalks out there that I doubt would evolve even if involved in the discussions.

There are other smalltalks out there that would be happy to evolve and offer their customers a 'backwards compatibility' library or the like. What is required to get 'a' smalltalk to evolve:

• Their entire base must follow the new rule(s)
• When a backwards compatibility is applied, the new rules must still hold valid

For the case of ifNil: - ifNil: would no longer return the non-nil value if it is not nil. If all senders in the base called whenNil: instead, then the behaviour of ifNil:, whether it returned nil or the LHS value would no longer matter, allowing the above two rules to apply in all circumstances.

But which Smalltalks have the balls to deliberate not be backwards compatible. This is very important. VERY IMPORTANT because languages such as Python, Perl, Ruby, so on and so forther do this all the time by simply being concise about what has changed.