Any reason for assigning block parameter in inject:into:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Any reason for assigning block parameter in inject:into:

keith1y

> Rather it's the confusion of sorting out what's going on in a piece of
> code
> when someone's decided variable names are too much work to invent,
> and reused parameter names for other quantities along the way.
>
> When you're reading a piece of unfamiliar code, every bit of solid
> ground helps;
> knowing that the value of a parameter doesn't change in the course
> of the method makes it that much easier to read and debug.
The particular annoyance that I noticed was when very short methods
which should have been one liners. end up as three of four because of
the need to declare and assign a second variable to represent the same
thing.

I dont think that debugging or readability is made easier by finding
that there are not two, often similar, variable names which reference
the same thing, one of which is immutable the other is not.

Keith

Reply | Threaded
Open this post in threaded view
|

Re: Any reason for assigning block parameter in inject:into:

Nicolas Cellier-3
In reply to this post by keith1y
Keith Hodges a écrit :
>
>>
>> Aaaaaaaaaaaaarrrrrrrghh! <runs screaming down the hall waving arms>
> Could you waive them in the direction to point me to the code where I
> can change the compiler to enable assignment to method params please.
> Keith
>
>
>

Easy:

TempVariableNode browse.

look at senders of isArg

Be prepared to live in your own world.

Nicolas


Reply | Threaded
Open this post in threaded view
|

Re: Any reason for assigning block parameter in inject:into:

David T. Lewis
In reply to this post by timrowledge
On Sun, Apr 29, 2007 at 09:03:43AM -0700, tim Rowledge wrote:
>
> A similar issue pertains for block arguments but we have the added  
> complication that even after ELEVEN YEARS we still don't have proper  
> closures in the default system and so the compiler can't really get  
> it's act together to work out that block args (and indeed block  
> temps) need to be treated appropriately.

Can someone give me a pointer to a brief explanation of why
closures were a hard problem for the original Squeak compiler?
I know there is some limitation of the original implementation,
and I know that this has been explained many times before,
but I can't seem to find a simple explanation of the original
problem. No debates please, I'm just curious about the reason
for the original limitation.

Thanks a lot,

Dave
 

123