2011/10/19 David T. Lewis <lewis at mail.msen.com>:
> 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
>

:) :) it would be great to plan a calendar of recurrent subjects

>
>