[self.]setter vs. local variable initialization

ruby-talk
1

Will Ruby 2.0 continue to interpret
    x = 5
as initializing a local variable vs. calling a setter method?

class A
    def x=(a); end
    def y(a); end
    def foo
        x = 5 # local var, not self.x=5
        y(5) # self.y(5)
    end
end

2

Hi,

···

In message "Re: [self.]setter vs. local variable initialization" on Fri, 5 Nov 2004 23:58:44 +0900, "itsme213" <itsme213@hotmail.com> writes:

Will Ruby 2.0 continue to interpret
   x = 5
as initializing a local variable vs. calling a setter method?

It will. x = 5 will be always interpreted as local variable
assignment, even when x= setter is defined.

              matz.

3

Thanks Matz.

Any chance the parenths/space requirement will go away in 2.0?

  method (1, 2, 3)

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message
news:1099667201.686203.12635.nullmailer@x31.priv.netlab.jp...

···

Hi,

In message "Re: [self.]setter vs. local variable initialization" > on Fri, 5 Nov 2004 23:58:44 +0900, "itsme213" <itsme213@hotmail.com> writes:

>Will Ruby 2.0 continue to interpret
> x = 5
>as initializing a local variable vs. calling a setter method?

It will. x = 5 will be always interpreted as local variable
assignment, even when x= setter is defined.

matz.

4

Hi,

···

In message "Re: [self.]setter vs. local variable initialization" on Sat, 6 Nov 2004 06:38:41 +0900, "itsme213" <itsme213@hotmail.com> writes:

Any chance the parenths/space requirement will go away in 2.0?

method (1, 2, 3)

Not sure. Only if I can make yacc rules smart enough to parse/detect

  method (arg1), arg2

              matz.

5

>Any chance the parenths/space requirement will go away in 2.0?
>
> method (1, 2, 3)

Not sure. Only if I can make yacc rules smart enough to parse/detect

  method (arg1), arg2

Are you talking about the warning you get if you do
  method (1, 2, 3)
instead of
  method(1, 2, 3)
?

I wonder if this is related to the bracket ambiguity, i.e.

  puts (a+b).abs => puts((a+b).abs)
  puts(a+b).abs => (puts(a+b)).abs

Neither of these generates a warning (1.8.2p2), but they do different things
depending on whether the space is there or not.

Trying a few combinations with more than one argument:

1. puts (a+b), c works - no warning is generated
2. puts(a+b), c fails
3. puts(a+b, c) works - no warning
4. puts (a+b, c) works - but generates a warning
5. puts (a+b) works - no warning
6. puts(a+b) works - no warning

So I'm not exactly sure why case 4 generates a warning, but case 5 doesn't.
In case 4, the brackets contain a comma, so surely it must be an argument
list, and therefore must be associated with the method name before it?

The example "method (arg1), arg2" seems to be an example of case 1, and that
works just fine under 1.8.2-p2

There is an ambiguity for

   foo(bar (a+b), c)

which generates
warning: parenthesize argument(s) for future version

but it seems to resolve it as

  foo(bar((a+b),c))

which I suppose is as reasonable a guess as any.

Regards,

Brian.

6

Hi,

Are you talking about the warning you get if you do
method (1, 2, 3)
instead of
method(1, 2, 3)
?

Yes.

Trying a few combinations with more than one argument:

1. puts (a+b), c works - no warning is generated
2. puts(a+b), c fails
3. puts(a+b, c) works - no warning
4. puts (a+b, c) works - but generates a warning
5. puts (a+b) works - no warning
6. puts(a+b) works - no warning

So I'm not exactly sure why case 4 generates a warning, but case 5 doesn't.
In case 4, the brackets contain a comma, so surely it must be an argument
list, and therefore must be associated with the method name before it?

Hmm, I had extended syntax rules little by little, so that the
argument warning behavior might be inconsistent. I will revisit it
soon.

              matz.

···

In message "Re: argument parenths" on Sat, 6 Nov 2004 22:38:16 +0900, Brian Candler <B.Candler@pobox.com> writes:

7

...

>4. puts (a+b, c) works - but generates a warning
>5. puts (a+b) works - no warning

...

>So I'm not exactly sure why case 4 generates a warning, but case 5
> doesn't. In case 4, the brackets contain a comma, so surely it must be an
> argument list, and therefore must be associated with the method name
> before it?

Hmm, I had extended syntax rules little by little, so that the
argument warning behavior might be inconsistent. I will revisit it
soon.

While I, personally, wasn't happy with the addition of the warnings, the rules
_are_ consistent, which is nice.

···

On Sunday 07 November 2004 21:20, Yukihiro Matsumoto wrote:

on Sat, 6 Nov 2004 22:38:16 +0900, Brian Candler <B.Candler@pobox.com> > writes:

--
### SER
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido
### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg

8

Hi,

···

In message "Re: argument parenths" on Mon, 8 Nov 2004 21:16:25 +0900, "Sean E. Russell" <ggg@ser1.net> writes:

Hmm, I had extended syntax rules little by little, so that the
argument warning behavior might be inconsistent. I will revisit it
soon.

While I, personally, wasn't happy with the addition of the warnings, the rules
_are_ consistent, which is nice.

I'm glad to hear that is consistent. Any opinion would be welcome.

              matz.