# Self and private setter **URL:** \ **Category:** ruby-talk\ **Created:** [18 December 2007 00:45 UTC](https://rubytalk.org/t/self-and-private-setter/43098 "2007-12-18T00:45:04Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Paul16](https://avatars.discourse-cdn.com/v4/letter/p/35a633/32.png) [@Paul16](https://rubytalk.org/u/Paul16)\ **Post date:** [18 December 2007 00:45 UTC](https://rubytalk.org/t/self-and-private-setter/43098/1 "2007-12-18T00:45:04Z")
A private method cannot be called with an explicit receiver -- even self -- except when calling a private setter method, because otherwise an assignment to a local variable will be assumed. For example: > **···** > > ----------------------- > class Q > >   def a1 >     @p = nil >     self.p=(3) >     @p >   end > >   def a2 >     @p = nil >     p=(3) >     @p >   end > >   private > >   def p=(obj) >     @p = obj >   end > end > ----------------------- > > CONSOLE > > > > Q.new.a1 > > =\> 3 > > > > Q.new.a2 > > =\> nil > ----------------------- > > Since there is already this exception to the rule, why not allow > explicitly using self for ALL private methods? What harm can be done? ---
**Author:** ![Jordan\_Callicoat](https://avatars.discourse-cdn.com/v4/letter/j/9de053/32.png) [@Jordan\_Callicoat](https://rubytalk.org/u/Jordan_Callicoat)\ **Post date:** [18 December 2007 01:10 UTC](https://rubytalk.org/t/self-and-private-setter/43098/2 "2007-12-18T01:10:03Z")
I'm pretty sure that's the difference between protected and private visibility; protected lets you use an explicit receiver (and maybe other things like children classes can also access the method?). But if you need to use private methods, you can always call them with an explicit receiver by using #send. Regards, Jordan > **···** > > On Dec 17, 6:44 pm, Paul \ wrote: > > > A private method cannot be called with an explicit receiver -- even > > self -- except when calling a private setter method, because otherwise > > an assignment to a local variable will be assumed. > > > > For example: > > ----------------------- > > class Q > > > >   def a1 > >     @p = nil > >     self.p=(3) > >     @p > >   end > > > >   def a2 > >     @p = nil > >     p=(3) > >     @p > >   end > > > >   private > > > >   def p=(obj) > >     @p = obj > >   end > > end > > ----------------------- > > > > CONSOLE > > > > \>\> Q.new.a1 > > =\> 3 > > \>\> Q.new.a2 > > > > =\> nil > > ----------------------- > > > > Since there is already this exception to the rule, why not allow > > explicitly using self for ALL private methods? What harm can be done? ---
**Author:** ![Jordan\_Callicoat](https://avatars.discourse-cdn.com/v4/letter/j/9de053/32.png) [@Jordan\_Callicoat](https://rubytalk.org/u/Jordan_Callicoat)\ **Post date:** [18 December 2007 01:29 UTC](https://rubytalk.org/t/self-and-private-setter/43098/3 "2007-12-18T01:29:59Z")
Found the article I was thinking of from Jamis Buck, where he talks about private/protected: [http://weblog.jamisbuck.org/2007/2/23/method-visibility-in-ruby](http://weblog.jamisbuck.org/2007/2/23/method-visibility-in-ruby) Regards, Jordan ---
**Author:** ![Gavin\_Kistner3](https://avatars.discourse-cdn.com/v4/letter/g/dfb087/32.png) [@Gavin\_Kistner3](https://rubytalk.org/u/Gavin_Kistner3)\ **Post date:** [18 December 2007 01:55 UTC](https://rubytalk.org/t/self-and-private-setter/43098/4 "2007-12-18T01:55:03Z")
I think you may be missing Paul's point. As shown in his sample code above (which I have not tried but assume to be correct), there is a particular syntax that allows self to be used with private methods. Paul's question is "why not always allow it?" 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](http://phrogz.net/ProgrammingRuby/language.html#accesscontrol) I don't have an answer to Paul's question, or for/against his proposal, but thought I'd clarify what I think may have been some miscommunication. > **···** > > On Dec 17, 6:08 pm, MonkeeSage \ wrote: > > > On Dec 17, 6:44 pm, Paul \ wrote: > > \> A private method cannot be called with an explicit receiver -- even > > \> self -- except when calling a private setter method, because otherwise > > \> an assignment to a local variable will be assumed. > > > > \> For example: > > \> ----------------------- > > \> class Q > > > > \> def a1 > > \> @p = nil > > \> self.p=(3) > > \> @p > > \> end > > > > \> def a2 > > \> @p = nil > > \> p=(3) > > \> @p > > \> end > > > > \> private > > > > \> def p=(obj) > > \> @p = obj > > \> end > > \> end > > \> ----------------------- > > > > \> CONSOLE > > > > \> \>\> Q.new.a1 > > \> =\> 3 > > \> \>\> Q.new.a2 > > > > \> =\> nil > > \> ----------------------- > > > > \> Since there is already this exception to the rule, why not allow > > \> explicitly using self for ALL private methods? What harm can be done? > > > > I'm pretty sure that's the difference between protected and private > > visibility; protected lets you use an explicit receiver (and maybe > > other things like children classes can also access the method?). But > > if you need to use private methods, you can always call them with an > > explicit receiver by using #send. ---
**Author:** ![Jordan\_Callicoat](https://avatars.discourse-cdn.com/v4/letter/j/9de053/32.png) [@Jordan\_Callicoat](https://rubytalk.org/u/Jordan_Callicoat)\ **Post date:** [18 December 2007 03:30 UTC](https://rubytalk.org/t/self-and-private-setter/43098/5 "2007-12-18T03:30:07Z")
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. Regards, Jordan > **···** > > On Dec 17, 7:53 pm, Phrogz \ wrote: > > > On Dec 17, 6:08 pm, MonkeeSage \ wrote: > > > > \> On Dec 17, 6:44 pm, Paul \ wrote: > > \> \> A private method cannot be called with an explicit receiver -- even > > \> \> self -- except when calling a private setter method, because otherwise > > \> \> an assignment to a local variable will be assumed. > > > > \> \> For example: > > \> \> ----------------------- > > \> \> class Q > > > > \> \> def a1 > > \> \> @p = nil > > \> \> self.p=(3) > > \> \> @p > > \> \> end > > > > \> \> def a2 > > \> \> @p = nil > > \> \> p=(3) > > \> \> @p > > \> \> end > > > > \> \> private > > > > \> \> def p=(obj) > > \> \> @p = obj > > \> \> end > > \> \> end > > \> \> ----------------------- > > > > \> \> CONSOLE > > > > \> \> \>\> Q.new.a1 > > \> \> =\> 3 > > \> \> \>\> Q.new.a2 > > > > \> \> =\> nil > > \> \> ----------------------- > > > > \> \> Since there is already this exception to the rule, why not allow > > \> \> explicitly using self for ALL private methods? What harm can be done? > > > > \> I'm pretty sure that's the difference between protected and private > > \> visibility; protected lets you use an explicit receiver (and maybe > > \> other things like children classes can also access the method?). But > > \> if you need to use private methods, you can always call them with an > > \> explicit receiver by using #send. > > > > I think you may be missing Paul's point. As shown in his sample code > > above (which I have not tried but assume to be correct), there is a > > particular syntax that allows self to be used with private methods. > > Paul's question is "why not always allow it?" > > > > 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:[The Ruby Language](http://phrogz.net/ProgrammingRuby/language.html#accesscontrol) > > > > I don't have an answer to Paul's question, or for/against his > > proposal, but thought I'd clarify what I think may have been some > > miscommunication. ---
**Author:** ![Gavin\_Kistner3](https://avatars.discourse-cdn.com/v4/letter/g/dfb087/32.png) [@Gavin\_Kistner3](https://rubytalk.org/u/Gavin_Kistner3)\ **Post date:** [18 December 2007 03:56 UTC](https://rubytalk.org/t/self-and-private-setter/43098/6 "2007-12-18T03:56:17Z")
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 #\ Other instances of the same class can still call protected methods on you, while only you yourself can call private methods. 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 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. > **···** > > On Dec 17, 8:15 pm, MonkeeSage \ wrote: > > > On Dec 17, 7:53 pm, Phrogz \ 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](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. ---
**Author:** ![Jordan\_Callicoat](https://avatars.discourse-cdn.com/v4/letter/j/9de053/32.png) [@Jordan\_Callicoat](https://rubytalk.org/u/Jordan_Callicoat)\ **Post date:** [18 December 2007 22:30 UTC](https://rubytalk.org/t/self-and-private-setter/43098/7 "2007-12-18T22:30:06Z")
> \> \> 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:[The Ruby Language](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 #\ > > 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 > **···** > > On Dec 17, 9:52 pm, Phrogz \ wrote: > > > On Dec 17, 8:15 pm, MonkeeSage \ wrote: > > \> On Dec 17, 7:53 pm, Phrogz \ wrote: ---
**Author:** ![Rick\_DeNatale1](https://avatars.discourse-cdn.com/v4/letter/r/bbce88/32.png) [@Rick\_DeNatale1](https://rubytalk.org/u/Rick_DeNatale1)\ **Post date:** [19 December 2007 00:19 UTC](https://rubytalk.org/t/self-and-private-setter/43098/8 "2007-12-19T00:19:57Z")
No, it only has to do this for protected methods not private methods. For private methods the only check that's needed is whether or not there was a specified receiver, no need to dig down the call stack. In the case of     self.x = y I'm almost certain that the parser turns this into the semantic equivalent of     setx(y) where setx is a fictional alias to the :x= message selector. In other words it's just syntactic sugar for a functional form method call. > **···** > > On 12/17/07, Phrogz \ wrote: > > > 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. > > -- > Rick DeNatale > > My blog on Ruby > [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/)