From: Trans <transfire@...>
Date: 2005-10-06T13:56:48+09:00
Subject: Re: foo= ... the only exception to the implicit-self rule ?


itsme213 wrote:
> Sorry to ask this again, but...
>
> *why* does
>
>   foo
> seems to always means
>   self.foo
>
> except that
>   foo= ...
> means
>   local variable foo = ...
> and not
>   self.foo=
>
> I find this keeps breaking up an otherwise uniform style in code, and almost
> leads me towards abandoning #foo=(value) as a setter, and using #foo(value)
> instead (with some distinguished sentinel value to distinguish getter from
> setter, which I hate!)

I agree and ten not to use them for this reason. I suspect most others
feel the same. One nice way to create a "setter" is:

  def foo(val=NilClass)
    unless val == NilClass
      @foo = val
    end
    @foo
  end

  foo      #=> nil
  foo(10)
  foo      #=> 10

Facets has this by the way (in next release):

  require 'facet/kernel/attr_setter'

  attr_setter :foo

> I know that otherwise one would somehow have to indicate local variables.
> Was this the main reason for this choice?

Yes. I think it was considered simply too "dangerous" to give setter
methods precedence. I'm not sure why since there tend to be quite few
of them, but I can see how it might catch one by suprise if their was a
setter defined that one didn't know about.

Some have suggested allowing a prefixed dot to mean 'self.', which
would help a little. Eg.

  .foo=

But all other suggestions I can recall seem just as bad as having to
use 'self.'

> Does this issue (distinguishing local variables) have to be dealt with
> anyway in any other contexts e.g. block-local variables?

Do you mean defining vars local to a block? Perhaps?

   { x := 1 }

I can only imagine it has been suggested before though.

T.