From: Daniel Carrera <dcarrera@...>
Date: 2003-01-11T08:09:52+09:00
Subject: Re: dot-equals method?

> If I say
>   obj .= foo
> is that calling obj.foo or a toplevel foo? What if
> both exist, which do you pick?

obj .= foo  is shorthand for  obj = obj . foo


> What about *other* method calls in the expression?
>   obj .= foo + bar

I think that it's a matter of presedence.  Should this be interpreted as

(obj .= foo) + bar
or
obj .= (foo + bar)

The first wouldn't make sense, so it should be the latter.  Thus, we get
the equivalent of :

obj = obj . (foo + bar)

I can't imagine how this could be used in a real program, but I think it's
the logically correct conclusion.  It's the same reason why, when I write:

num /= 3 + 2

It gets interpreted as

num = num / (3 + 2)

and not

num = (num / 3) + 2
or
num = (num / 3) + (num / 2)

> Would you allow this?
>   obj .= +(3)
> instead of
>   obj += 3
> ? No one would want to do that, but it's consistent
> to allow it.

I would allow it yes.

I can see your point.  However, I think I'm still inclined in favour of
'.='.  The '.=' has a unique, logically consistent, interpretation.

Chris mentioned:

str = 'olleh'
str .= reverse + ' world'

I'm not sure if someone would try to do that.  I can't see how (s)he
could expect this to produce the desired result. There are two possible
ways to parse this depending on presedence:

(str .= reverse) + ' world'
and
str .= (reverse + ' world')

Neither would produce what (s)he wants.

Most people think that this is ambiguous, and that probably means that it
is.  But I just don't see why the parsing is ambiguous.

Just my $0.02

Daniel Carrera
Graduate Teaching Assistant.  Math Dept.
University of Maryland.  (301) 405-5137