[Pharo-project] Cannot assign a parameter

laurent laffont laurent.laffont at gmail.com
Sun Nov 28 15:48:55 CET 2010


OK thank you.

Little joke: http://magaloma.blogspot.com/2010/11/revenge-of-smalltalk.html

Laurent.

On Sun, Nov 28, 2010 at 3:36 PM, Adrian Lienhard <adi at netstyle.ch> 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 <maxleske at gmail.com> 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 <maxleske at gmail.com>
> 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/
> >>>
> >>>
> >>
> >>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20101128/8e3f8070/attachment.htm>


More information about the Pharo-project mailing list