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.



> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20111018/db9a59ca/attachment.htm