From: MonkeeSage <MonkeeSage@...>
Date: 2007-12-19T07:30:06+09:00
Subject: Re: self and private setter

On Dec 17, 9:52 pm, Phrogz <phr...@mac.com> wrote:
> On Dec 17, 8:15 pm, MonkeeSage <MonkeeS...@gmail.com> wrote:
>
> > On Dec 17, 7:53 pm, Phrogz <phr...@mac.com> wrote:
> > > The distinction between private and protected is only superficially
> > > about whether an explicit receiver may be used. Primarily it is the
> > > difference between...well, read for yourself:http://phrogz.net/ProgrammingRuby/language.html#accesscontrol
>
> > NP. I understand the question, I just answered it indirectly. Viz., it
> > seems to me that protected is specifically meant for allowing access
> > with a receiver, and unless it is necessary to use private (e.g.,
> > someone else's code), using protected is the Right Thing To Do(R) when
> > you want access through a receiver. There would seem to be no
> > difference between private/protected if private methods could be
> > called with explicit the self receiver (see the example output in
> > Jamis' article, also the link in the fifth comment). Maybe I'm missing
> > something though.
>
> There would still be this difference:
>
> class Foo
>   def call_prot( someone_else )
>     someone_else.prot
>   end
>
>   def call_priv( someone_else )
>     someone_else.priv
>   end
>
>   protected
>     def prot; "prot"; end
>
>   private
>     def priv; "priv"; end
> end
>
> f1 = Foo.new
> f2 = Foo.new
>
> p f1.call_prot( f2 )
> #=> "prot"
>
> p f1.call_priv( f2 )
> #=> NoMethodError: private method 'priv' called for #<Foo:0x281e50>
>
> Other instances of the same class can still call protected methods on
> you, while only you yourself can call private methods.

Not trying to be contrary, but I think calling #call_priv with f1 as
the argument should raise the same exception (no receiver allowed,
even self). I'm not sure it has anything to do with different
instances...

class Foo
  def call_priv; priv; end
private
  def priv; "priv"; end
end
f1 = Foo.new
f2 = Foo.new
m = Foo.instance_method(:call_priv)
p m.bind(f1).call # => "priv"
p m.bind(f2).call # => "priv"

I have a feeling I'm still missing something? Were you talking about a
proposal for the way private could work if explicit self was allowed,
in order to distinguish it from protected?

> Paul's proposal/
> question would be if this works already (which it does):
>
>   class Foo
>     def call_bar_set( val )
>       self.bar = val
>     end
>     private
>       def bar=( val ); "yay"; end
>   end
>
>   Foo.new.call_bar_set( 42 )
>
> then why not allow this to work:
>
>   class Foo
>     def call_bar
>       self.bar
>     end
>     private
>       def bar; "yay"; end
>   end
>
>   Foo.new.call_bar

I understand. I also don't know enough about ruby under the hood to be
for / against the suggestion. But I'm still not sure it is needed or
desirable (protected still seems like the right tool for the job to
me, or using #send to bypass visibility restrictions if you can't
choose the visibility yourself).

> I suppose it _might_ be a _small_ extra burden on the runtime to allow
> this:
>
>   class Foo
>     def call_bar( someone_else )
>       someone_else.bar
>     end
>     private
>       def bar; end
>   end
>
> ...as the runtime would have to check if 'someone_else' was the same
> as 'self' inside call_bar. Since it already has to check if the 'self'
> inside call_bar is of the same class as the class as 'someone_else',
> this doesn't seem particularly burdensome, however.

Regards,
Jordan