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
|