> Message: 11
> Date: Thu, 02 Dec 2004 04:56:31 -0800
> From: Blake <blake at kingdomrpg.com>
> Subject: Re: Perhaps naive question about the colon.
> To: "The general-purpose Squeak developers list"
> 	<squeak-dev at lists.squeakfoundation.org>
> Message-ID: <opsidswhd1zb486t at wynorski>
> Content-Type: text/plain; format=flowed; delsp=yes;
> 	charset=iso-8859-15
>
> On Thu, 2 Dec 2004 12:47:18 -0000, Frank Shearar
> <Frank.Shearar at rnid.org.uk> wrote:
>
>>> Caveman find: flint gather: twigs light:fire.
>>
>> This actually sends the message #find:gather:light. If you mean to 
>> send
>> #find: then #gather: then #light: you need disambiguate using 
>> brackets:
>
> Doh! Right. See, you can tell I haven't used them much lately. I'm the
> same way with C. I'll start out writing
>
> C = C + 1;
> D = C + 1;
>
> then:
>
> C++;
> D = C;
>
> then
>
> D = C++; //or is it D = ++C; ?
>

Actually, the two are not the same.   In the first example, you aren't 
setting D to C as you do in the latter, you are instead using the value 
of C.  In a simple integer evaluation, it doesn't (always) make a 
difference, but when applying the concept to more complicated 
structures/objects/etc., it can be a problem.  (BTW, the ++ operator 
changes the value of C, not just what it would be currently evaluated 
at.  That is D = C++; versus D = C + 1; causes C to have a different 
value whereas that of D is the same).

Anyway, one thing that I find really interesting about this 
conversation is that it illustrates the confusion that can arise over 
syntactical conventions and how this confusion can lead to errors, etc. 
  I think that this is particularly important given the history of 
smalltalk and its aversion to such complexity.  In other words, while 
implementation can devolve into splitting hairs, smalltalk is supposed 
to be (somewhat) intuitive and straightforward to grasp (note that this 
does not mean "simple" in terms of capability).  The initial question 
is important because one method seems intuitive to (at least one) 
programmer, but the result may be unexpected.  Therefore, why is this 
method intuitive and how do we prevent the language from following 
grammatical trends that would obscure the "best" way of writing 
something?

> I always fall back on plain code but get more comfortable with the 
> idioms
> for better (Smalltalk) or worse (C)<s>.

And when one is changing code, the result may be unexpected.  Again, 
there is a certain danger in this process.

A bit of a ramble - sorry

Robert Pratte