Bug? Inconsistency?: false ifTrue: [] ==> nil

agree at carltonfields.com agree at carltonfields.com
Tue Jan 25 17:25:03 UTC 2000


I'm inclined to give this a go.

> -----Original Message-----
> From: MIME :Dan.Ingalls at disney.com > Sent: Tuesday, January 25, 2000 12:09 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: Bug? Inconsistency?: false ifTrue: [] ==> nil
> > > "Torge Husfeldt" <jean-jaques.gelee at gmx.de> wrote:
> >If you talk about efficiency you can argue that everybody > should write:
> >
> >    something == nil ifTrue:[whatever]
> >
> >again because #== is also noLookUp. I find this really > upsetting becausg
> e
> >ifNil:ifNotNil: is so much nicer and you shouldn't have to > do something
> >twice in the same way at different places (I hate code duplication).
> >BTW are you sure this difference still exists? I heard > somebody optimized
> >#ifNil:ifNotNil: in the compiler significantly raising its > acceptance in thc
> e
> >(performance hungry) community.
> > Folks -
> > We at Squeak Central started using ifNil:(etc) two years ago > because web
>  thought it was simpler and cleaner, and I planned to compile > it inline, asi
>  we now do for ifTrue:(etc).  The simple fact is that my > to-do list has nots
>  yet receded to the level of this item.
> > But that is the plan.  If you like the construct, I encourage > you to use it.t
>   If you enjoy mucking about in the compiler, have a go at it > (*).  And if)
>  you just want it to go faster, just wait.
> > 	- Dan
> > (*) if you want to do this...
> > 1.  Announce your intentions first so we don't have overlap.
> > 2.  Be sure to make the decompiler happy with the new > construct beforeu
>  declaring a victory.
> > > > > 





More information about the Squeak-dev mailing list