On Apr 29, 2007, at 16:09 , Colin Putney wrote:

> On Apr 29, 2007, at 10:03 AM, tim Rowledge wrote:
>
>> Assigning some new object to the tag used for a parameter is  
>> confusing and pointless because it can have no effect outside the  
>> local context despite *looking like* it might replace the object  
>> to someone not familiar. To prevent that confusion, the compiler  
>> prevents the assignment.
>
> Interesting. As far as I can tell, you're the only poster in this  
> thread that thinks assigning to a parameter name implies that the  
> parameter was passed by reference. Lukas was just complaining that  
> parameter slots are read-only, and giving examples of cases where  
> it would be nice to be able to write to them. I occasionally feel  
> this way too - making parameters different from other temps feels  
> arbitrarily inconsistent.
>
>  I wonder if this is a sign of changing times. After all,  
> "confusion" is a mismatch between expectations and reality. Perhaps  
> were seeing a change in expectations? Back in the days of yore,  
> people were coming to Smalltalk from low-level languages where it  
> was possible to pass pointers around, and returning a value through  
> a pass-by-reference parameter was a common idiom. These days,  
> people who are interested in Smalltalk are probably coming from  
> other dynamic languages where that's not possible, and treating  
> parameters as just another temp feels natural.
>
> Personally, I think it would be nice to be able to write to  
> parameter slots, but it's not worth breaking compatibility with  
> other Smalltalks.

+1

I wouldn't expect assigning to a variable to affect the sending  
method. I think of method arguments as temps. Which they are, in  
Squeak at least. I actually don't see a compelling reason to disallow  
assigning to method args, except for stylistic ones.

I'd argue similarly for block parameters, but the current compiler  
does not do the Right Thing when assigning to them in some  
situations. It's unacceptable to get different results for these two  
expressions:

Array streamContents: [:s | (1 to: 5) do: [:i | s nextPut: (i := i +  
1)]]

Array streamContents: [:s | 1 to: 5 do: [:i | s nextPut: (i := i + 1)]]

The optimization of #to:do: expects the block parameter to not be  
assigned to.

- Bert -