self and private setter

P

Paul

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
 
M

MonkeeSage

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


=> nil
Click to expand...

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
 
P

Phrogz

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.
Click to expand...

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

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.
 
M

MonkeeSage

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

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.
Click to expand...

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
 
P

Phrogz

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.
Click to expand...

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. 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.
 
M

MonkeeSage

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.
Click to expand...

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
Click to expand...

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.
Click to expand...

Regards,
Jordan
 
R

Rick DeNatale

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.
Click to expand...

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

implicit vs explicit self in private methods 3
private and self 1
Question about "protected" and "private" 4
calling private accessors 3
private vs. protected question 3
Ruby1.9, instance_eval and private methods 5
private method calls...why can't you use self.priv_method syntax? 2
private #initialize 4

Members online

Total: 82 (members: 3, guests: 79)
Robots: 198

Forum statistics

Threads
473,981
Messages
2,570,187
Members
46,731
Latest member
MarcyGipso

Latest Threads

Top