2011/10/19 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Tue, Oct 18, 2011 at 2:01 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> 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:
>
> This is a great example.  At least for me the first form is much clearer,
> expressing my intent to find a window that is selected and not a hierarchy
> window.  The problem in teh former is that there is no inverse of
> isHierarchy.  isNotHierarchy is overkill (but not I think isNotEmpty, as
> there are far more use-cases).  Calling the inverse something like
> "isNormal" is just not descriptive enough.  So in this case I had to use
> isHierarchy not to compose the predicate I wanted.
>

That's what I thought. I started refactoring just to push these
absolutist ideas to the limits of absurdity.
But your example soon was disturbing. I agree to not refactor it.
We can say that using negation MAY be intention obscuring and is thus
questionnable, but it would be a great mistake to generalize and
answer prematurely to this legitimate question with a single
pre-established answer.
We shall not carve such ban in stone.
That's funny, because I got exactly this discussion yesterday with
colleagues which had prepared stone tablets and chisel.
An excuse : they program in C and ! is effectively really intention
obscuring (hardly readable to my brain & eyes).

Nicolas

>>
>> Nicolas
>>
>> >>
>> >> And I read "~~" as "not identical" which also has a mental "not" in it,
>> >> so
>> >> I prefer "== ifFalse" :)
>> >
>> > Ah, there we differ.  I view == and ~~ as complementary predicates.  If
>> > I'm
>> > writing foo == bar ifTrue: I'm clearly selecting, and foo ~~ bar ifTrue:
>> > I'm
>> > clearly rejecting, but foo == bar ifFalse: is IMO worse (more
>> > cognitively
>> > demanding) than foo ~~ bar ifTrue:.
>> >
>> >
>> >>
>> >> - Bert -
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > best,
>> > Eliot
>> >
>> >
>> >
>> >
>>
>
>
>
> --
> best,
> Eliot
>
>
>
>