On Thu, 2 Dec 2004 14:57:09 -0600, Robert Pratte <csrpp at eiu.edu> wrote:

>> 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).

Yeah, I know. It's subtle. I hate subtle. (In programming, anyway.<s>)

> 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?

Exactly why I brought it up. I've been wondering if there isn't an even  
simpler, clearer way to express things.

>> 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

I appreciate the input.