On Tue, Oct 18, 2011 at 11:01:41PM +0200, Nicolas Cellier wrote:
> 2011/10/18 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> > On Tue, Oct 18, 2011 at 1:58 AM, Bert Freudenberg <bert at freudenbergs.de>
> > wrote:
> >>
> >> On 18.10.2011, at 05:11, Chris Muller wrote:
> >>
> >> > (From vm-dev list)
> >> >> But I much prefer foo ~~ bar ifTrue: than foo == bar ifFalse:.
> >> >
> >> > Hi Eliot. ?May I ask why you prefer the former over the latter?
> >> >
> >> > I'm interested because I'm working on an application where the folks
> >> > involved prefer something similar, to where they write (expr) not
> >> > ifTrue: [ ] rather than (expr) ifFalse: [ ].
> >> >
> >> > I know you wouldn't do that but your statement definitely piqued my
> >> > surprise and curiosity.
> >>
> >> Maybe this is a clue: very few other programming languages have an
> >> "else"-case without a preceding "if true". So maybe for people versed in
> >> multiple languages the ifFalse: feels wrong?
> >
> > For me, it's not about feeling right or wrong, it's about directly
> > expressing intent. For example, in some loop where a predicate is being used
> > to select or reject elements I would write "obj predicate ifTrue:" if I were
> > looking for the element based on predicate and "obj predicate ifFalse:" if I
> > were trying to filter-out elements based on predicate, just as I'd write
> > collection select: [:e| e predicate] to select items based on predicate
> > and?collection reject: [:e| e predicate] to filter them out, and I would
> > /not/ write?collection select: [:e| e predicate not] to filter them out
> > unless performance was really really important (since reject: adds another
> > block activation for each element). ?I'm trying to communicate whether I'm
> > selecting or rejecting based on predicate, and not wanting the reader to go
> > through mental hoops by internally collapsing predicate not ifFalse: to
> > predicate ifTrue: and vice verse.
> >>
> >> I personally like "expr ifFalse:" better than "expr not ifTrue:".
> >
> > Agreed. ?expr not ifTrue: & expr not ifFalse are perverse.
> >
> 
> He He, Eliot, I saw your initials stamped on this quite defensive code:
> 
> 	(self selectedClass notNil
> 	 and: [multiWindowState notNil
> 	 "Can only support multi-window if original window has all the right panes."
> 	 and: [multiWindowState prototype isHierarchy not]]) ifTrue:
> 
> Probably a negative day ;) (no offense, I'd like to hide all my own
> production away)
> However, I'm not sure whether (or not) the negated form makes the
> intention clearer...
> 
> 	(self selectedClass isNil
> 	 or: [multiWindowState isNil
> 	 "Can only support multi-window if original window has all the right panes."
> 	 or: [multiWindowState prototype isHierarchy]]) ifFalse:


And in the category of "no good deed goes unpunished" the nominees are:

Eliot Miranda, for attempting to propose a tiny performance enhancement
primitive, for which we reward him with a full blown language war,
destined to be enthusiastically reargued on an annual basis for many
years to come...

;-)

Dave