Well in 3.8 that method reads like this:

String>>asPacked
	"Convert to a longinteger that describes the string"

	^ self inject: 0 into: [ :pack :next | pack := pack * 256 + next  
asInteger ].

And the assignment is meaningless, perhaps the author did not fully  
understand #inject:into:. It should certainly be removed.

- Bert -


On Apr 29, 2007, at 14:38 , nicolas cellier wrote:

> Hi Lukas,
>
> I perfectly understand your argument. duplicating args in  
> temporaries is bad.
>
> But you reformulate Tim so well: It might also confuse beginners,
> that i cannot believe you did not understand him.
> He did not mean anything else.
>
> And I feel like the example given by stephane is exactly a case of  
> such confusion.
>
> asPacked
>     ^ self
>         inject: 0
>         into: [:t1 :t2 | t1 := t1 * 256 + t2 asInteger]
>
> unless it is just an effect of Decompiler?
> Who would name block variables t1 and t2 but the Decompiler?
>
> However, stupid me, one thing I cannot understand is the reason to  
> do so for ImageSegment. Any light on this?
>
>
> Nicolas
>
> Lukas Renggli a écrit :
>>> Perhaps if you think of it along the lines of:-
>>> a) names in a method are just local tags for programmer convenience
>>> so that you don't have to keep it all in your head as you read/write
>>> code,
>>> b) objects passed into the method as parameters are bound to the
>>> parameter tags;
>>> it might help.
>> I don't understand what you mean.
>> Temps and method and block arguments are all slots in some context
>> object. It is only the compiler that tries to stop you in an
>> inconsistent way from assigning to some of these slots. I initially
>> asked because I find that an unnecessary restriction. Usually the
>> philosophy of Smalltalk is to open the possibilities that the
>> programmer has, not to arbitrarily restrict them.
>> I don't say it is good style to assign to arguments. It might also
>> confuse beginners, I agree. I don't even suggest to change the
>> language. I only asked why this restriction was made in the first
>> place. Luckily you can always use the debugger/inspector or
>> thisContext tempAt:put: (there are a few methods that actually do  
>> that
>> in the standard image) to change these values.
>> Lukas
>
>