(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.
Ah, now I just saw the ~= discussion, sorry..
On Mon, Oct 17, 2011 at 10:11 PM, Chris Muller asqueaker@gmail.com 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.
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?
I personally like "expr ifFalse:" better than "expr not ifTrue:". And I read "~~" as "not identical" which also has a mental "not" in it, so I prefer "== ifFalse" :)
- Bert -
On 18 October 2011 09:58, Bert Freudenberg bert@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?
I personally like "expr ifFalse:" better than "expr not ifTrue:". And I read "~~" as "not identical" which also has a mental "not" in it, so I prefer "== ifFalse" :)
Ruby and Common Lisp have "unless"... and I find I almost never use them.
frank
Hi Guys,
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?
I personally like "expr ifFalse:" better than "expr not ifTrue:". And I read "~~" as "not identical" which also has a mental "not" in it, so I prefer "== ifFalse" :)
- Bert -
Allow me to throw out an outside the box (programming box) thought. If one is able to mentally read "x ~= y ifTrue:..." or "x == y ifFalse:..." all in one look, I don't think it matters much as they know what the sentence says instantly. It then becomes a matter of what they are use to.
For those of us who read those sentences in two parts: "x ~= y" and "ifTrue:...", the "not" being included in the comparison is preferred as it tells us up front what the comparison is about. Then the second part tells us what is being done about it. I hope helps and makes some sense.
Lou ----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
Hi,
In general negation can be confusing, but negations are not only syntactically. You can find negation in the semantic also, e.g.: variable names.
You can find yourself with a variable name which express a negation, e.g.: * abandoned* (I must admit this is not the majority of the cases)
In such situations, it's really convenient to have different combinations that allow you to write the code that reads better. Which read better between these?
abandoned not ifTrue: [] abandoned ifFalse: []
Maybe what you will discover is that most of the time you use ifTrue... maybe you negate the variable or not... I think is not what you like the most, but what you write most of the time that tent to be readable.
Regards, Erlis
On Tue, Oct 18, 2011 at 9:20 AM, Louis LaBrunda Lou@keystone-software.comwrote:
Hi Guys,
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?
I personally like "expr ifFalse:" better than "expr not ifTrue:". And I
read "~~" as "not identical" which also has a mental "not" in it, so I prefer "== ifFalse" :)
- Bert -
Allow me to throw out an outside the box (programming box) thought. If one is able to mentally read "x ~= y ifTrue:..." or "x == y ifFalse:..." all in one look, I don't think it matters much as they know what the sentence says instantly. It then becomes a matter of what they are use to.
For those of us who read those sentences in two parts: "x ~= y" and "ifTrue:...", the "not" being included in the comparison is preferred as it tells us up front what the comparison is about. Then the second part tells us what is being done about it. I hope helps and makes some sense.
Lou
Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
For those of us who read those sentences in two parts: "x ~= y" and "ifTrue:...", the "not" being included in the comparison is preferred as it tells us up front what the comparison is about. Then the second part tells us what is being done about it. I hope helps and makes some sense.
That's a great thought, thanks. It made me remember, a couple of times (cough), I have focused too quickly on the first-part (the condition) and then the second part (the what-to-do) so quickly that missed the middle part (the "ifFalse:") and made me mis-interpret the code momentarily because I assumed it was the true case..
On Tue, Oct 18, 2011 at 1:58 AM, Bert Freudenberg bert@freudenbergs.dewrote:
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.
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 -
2011/10/18 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 18, 2011 at 1:58 AM, Bert Freudenberg bert@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.
Well guys, while I agree, I just browsed senders of not and that's 1175 senders to refactor :) Well, maybe NOT all the senders (hey how you translate this, (senders allSatisfy: [:e | e shouldBeRefactored]) not or: [(senders anySatisfy: [:e | e shouldBeRefactored not]) or: [(senders noneSatisfy: [:e | e shouldBeRefactored not ]) not]] I tend to slightly dislike the last triple negation ;)
Among the senders some answer true to your filter predicate, like select: predicate not / anyStatisfy: predicate not / but others are composed logic... Some like
checkName: aFileName fixErrors: fixing ...snip... hasBadChars := fName ~= correctedName. (hasBadChars and:[fixing not]) ifTrue:[^self error:'Invalid file name']. hasBadChars ifFalse:[^ fName]. ^ correctedName
shall easily become
fname = correctedName ifTrue: [^fname]. fixing ifTrue: [^correctedName]. ^self error: 'Invalid file name'
Some are tougher and would probably deserve a new selector like
(self isPointers or: [ self isWords not ]) ifTrue: [ ^self ].
See https://code.google.com/p/pharo/issues/detail?id=2230 to just measure how badly we tend to misunderstand negation and what mistakes we make (same as subtraction is lot harder to learn than addition)
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:.
same for noneSatisfy: , notNil etc...
- Bert -
-- best, Eliot
2011/10/18 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 18, 2011 at 1:58 AM, Bert Freudenberg bert@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:
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
On Tue, Oct 18, 2011 at 2:01 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/10/18 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 18, 2011 at 1:58 AM, Bert Freudenberg bert@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 rightpanes." 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 rightpanes." 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
2011/10/19 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 18, 2011 at 2:01 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2011/10/18 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 18, 2011 at 1:58 AM, Bert Freudenberg bert@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
On Tue, Oct 18, 2011 at 11:01:41PM +0200, Nicolas Cellier wrote:
2011/10/18 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 18, 2011 at 1:58 AM, Bert Freudenberg bert@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
2011/10/19 David T. Lewis lewis@mail.msen.com:
On Tue, Oct 18, 2011 at 11:01:41PM +0200, Nicolas Cellier wrote:
2011/10/18 Eliot Miranda eliot.miranda@gmail.com:
On Tue, Oct 18, 2011 at 1:58 AM, Bert Freudenberg bert@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
On 19.10.2011, at 07:20, Nicolas Cellier wrote:
2011/10/19 David T. Lewis lewis@mail.msen.com:
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
Namespace discussions aren't due until Spring time. Followed by method chaining, and then arrow-assignments.
- Bert -
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
David T. Lewis -
Eliot Miranda -
Erlis Vidal -
Frank Shearar -
Louis LaBrunda -
Nicolas Cellier