Wouldn't debugging be harder if arguments could be assigned to? Where
would you keep the original argument? If you did that, wouldn't it be
more costly to run methods?
On 11/28/10 6:36 , Adrian Lienhard wrote:
Its an artificial restriction. Method arguments are just like temps, i.e., the
interpreter does not distinguish between the two; its only the compiler that
restricts assignments to arguments (I'm not 100% sure, but I assume that this
still holds with Eliot's new closure compiler).
I think it would be nice to be able to assign to arguments. In some cases they
make for concise and better readable code (I got used to this for instance in
Python and JavaScript). For example, consider a method that uses an argument in
multiple places and you figure that you need to handle the case in which the
argument is nil. You just add a line like: arg := arg ifNil: [ 0 ]. Without
argument assignment you would need to create a temp var with a different name
and change all usage of the old arg variable.
Block args had been writable until the new closure compiler was introduced,
which by default disallows arg assignments. I don't remember what the rationale
for this change was (?).
On the flip side, one has to consider code portability. For projects like
Seaside this probably is a no go. But for projects that don't need to be ported
I think it would be a worthwhile change. Projects that need to avoid
portability troubles with other dialects should use Lint rules (stuff like this
is better checked by Lint than the compiler...).
I'll also note that this topic was discussed before and some people argued that
argument assignments can lead to bad code quality...
Cheers,
Adrian
On Nov 28, 2010, at 11:41 , Max Leske wrote:
+1
On 28.11.2010, at 11:26, laurent laffont wrote:
I would like to know whether it's a design choice or a technical obstacle.
I've seen:
Parser>>assignment: varNode
" var ':=' expression => AssignmentNode."
| loc start |
(loc := varNode assignmentCheck: encoder at: prevMark +
requestorOffset)>= 0
ifTrue: [^self notify: 'Cannot store into' at: loc].
.....
TempVariableNode>>assignmentCheck: encoder at: location
^((self isBlockArg and: [Parser allowBlockArgumentAssignment not])
or: [self isMethodArg])
"<-- not allowed !"
ifTrue: [location]
ifFalse: [-1]
But no explanation :(
Laurent
On Sun, Nov 28, 2010 at 10:59 AM, Max Leske<[email protected]> wrote:
Yeah, that's true, I've noticed that too. I guess it's on purpose but I have no
idea. AFAIK you can't assign a new value to a parameter anywhere in the method
not only when using blocks. Maybe it's not possible because there is not really
a 'variable' but only a reference. So assigning a new value to the parameter
would effectively override the reference. But don't trust me on this....
Cheers,
Max
On 28.11.2010, at 10:54, laurent laffont wrote:
Sorry
foo: n
^[:i| n := n+i. ]
vs
foo: n
|s|
s := n.
^[:i| s := s+i. ]
Laurent
On Sun, Nov 28, 2010 at 10:51 AM, Max Leske<[email protected]> wrote:
In the first example you didn't declare 's':
foo:n
^ [ :i || s | s:= s+i ]
Or did I misunderstand the question?
Cheers,
Max
On 28.11.2010, at 10:30, laurent laffont wrote:
Hi,
I can't write
foo: n
^[:i| s := s+i. ]
but
foo: n
|s|
s := n.
^[:i| s := s+i. ]
Why ?
Cheers,
Laurent Laffont
Pharo Smalltalk Screencasts: http://www.pharocasts.com/
Blog: http://magaloma.blogspot.com/
.
