Some Self ideas
arning at charm.net
Fri Jan 19 23:59:48 UTC 2001
On Fri, 19 Jan 2001 18:28:39 -500 "Lex Spoon" <lex at cc.gatech.edu> wrote:
>> > 5) Readability again. My eyes catch the .
>> And what does the  tell you?
>> A - That you have encountered one of those idiosyncratic messages, #ifTrue:#ifFalse:, which happens to be a bit peculiar as to what kind of arguments it will accept and how they are written?
>> B - That the programmer has decided to defer evaluation of the code within until such time as it is really needed?
>> C - Something else?
>> My eyes translate the  as B. Unnecessary brackets do as little for readability in my eyes as unnecessary parentheses. I would prefer the brackets to mean: "Don't evaluate this code right now. just package it up so that it can be evaluated later, if need be."
>To be pedantic, this is precisely what the  *does* mean in
>ifTrue:ifFalse: -- the code is packaged up and is possibly evaluated
>Agreed that it's kind of annoying to be explicit about things like that,
>but it *is* what's going on.
I agree. My point was that being required in the case of this small family of messages to use a literal block or a simple instance variable is a concession to the compiler writing gods. Other messages like #do:, #select:, etc. enforce no such restriction. This makes it harder, rather than easier to explain, IMHO.
My disquiet with the implementation of #ifTrue:.. is that the brackets are required even when it is of no concern to me whether the code gets evaluated unnecessarily or not. Or even when I want both to be evaluated. Consider:
a := a + 1.
b := b + 1.
^cond ifTrue: [a] ifFalse: [b]
could be written as
^cond ifTrue: (a _ a + 1) ifFalse: (b _ b + 1)
if the compiler were a little friendlier to harder-to-optimize code and Object understood #value. If we changed the selector in the example to
^cond eitherThis: (a _ a + 1) orThat: (b _ b + 1)
we sould have something syntactically equivalent and probably no one would bat an eye. We seem to be hung up on special treatment for #ifTrue:ifFalse: and I don't quite understand why.
>> > cond ifTrue: 1->2 ifFalse: 2->2
>> > would return 2 in both cases!
>> Well, it basically does that now.
>The point is, when you start, it looks so cool being able to do this:
> cond ifTrue: 2 ifFalse: 3
>but the idiom breaks down into the general case very quickly, and it's
>not even a clean break -- there are plenty of border cases for people to
>get snagged on. The above is one of them, and I'd hate trying to
>explain to a newbie what was happening.
If were are trying to explain things to newbies, I suspect there a a bunch of things we wouldn't show them on the first day, but that does not argue for a language limited to newbie features.
More information about the Squeak-dev