I'm wondering about definition of method in top level.
puts RUBY_VERSION #=> 2.1.5
def greet
"hello, world"
end
class Object
greet #=> "hello, world"
end
Why does greet act like private class method?
puts RUBY_VERSION #=> 2.1.5
def greet
"good morning"
end
# case 1
Object.private_methods(false).grep /greet/ #=> []
# case 2
Object.private_instance_methods(false).grep /greet/ #=> [:greet]
# case 3
Object.private_methods(true).grep /greet/ #=> [:greet]
In case 3, I found that greet is a private class method. But I'm wondering which class owns greet as a private class method. Object inherits itself?
Edit
I update my question.
Question #1
Does definition of method mean adding some methods in Object as private instance method.
Is this correct ?
Question #2
Object is an instance of Class. So, Object owns private class methods. These methods as private instance methods in Class.
Is this correct ?
Question #3
depends on question #1 and #2. Class inherits Object. So, Class owns greet as private class method and private instance method.
Is this correct ?
Why does greet act like private class method?
It doesn't. It acts like a private instance method. (In fact, there are no class methods in Ruby, only instance methods. The question is not whether a method is an instance method or a class method, rather it's what class the instance method is defined in.)
Methods defined at the top-level become private instance methods of Object.
# case 1
Object.private_methods(false).grep /greet/ #=> []
# case 2
Object.private_instance_methods(false).grep /greet/ #=> [:greet]
# case 3
Object.private_methods(true).grep /greet/ #=> [:greet]
In case 3, I found that greet is a private class method.
Like I said above: there are no class methods in Ruby.
greet is a private instance method of Object. Object is an instance of Class, Class is a subclass of Module, Module is a subclass of Object, ergo Object is an instance of Object i.e. itself.
Put another way: methods defined in Object are available for all objects. Classes are objects, too, ergo methods defined in Object are available for all classes, including Object.
But I'm wondering which class owns greet as a private class method.
None. There are no class methods in Ruby. greet is a private instance method of Object.
Object inherits itself?
No. Object is an instance of itself.
Question #1
Does definition of method mean adding some methods in Object as private instance method.
Is this correct ?
Methods defined at the top-level become private instance methods of Object.
Question #2
Object is an instance of Class. So, Object owns private class methods. These methods as private instance methods in Class.
Is this correct ?
I cannot parse your question, sorry.
However, there are no private instance methods of Class in your examples. The only method in your example is greet, which is a private instance method of Object, not Class.
If you want to know who owns a method, you can just ask Ruby:
method(:greet).owner
# => Object
Question #3
depends on question #1 and #2. Class inherits Object. So, Class owns >greet as private class method and private instance method.
Is this correct ?
No. There are no class methods in Ruby, only instance methods. And greet is not owned by Class, it is a private instance method of Object:
method(:greet).owner
# => Object
Using irb, defining greet at the top-level does NOT define greet as a private method, at least using ruby 2.x:
$ irb
> RUBY_VERSION
=> "2.3.0"
> def greet; "hi"; end
=> :greet
> Object.methods.grep /greet/
=> [:greet]
> Object.private_methods.grep /greet/
=> []
> Object.private_instance_methods.grep /greet/
=> []
In ruby, a "private method" is one that cannot be called with an explicit "receiver" in the usual way. (See e.g. this SO page.) Since self.greet and Object.greet both produce the same result as greet, it follows that greet (defined at the top-level in irb) cannot be a private method.
The situation is different when using the ruby compiler.
Related
From Wikibooks' Ruby Programming/Overview:
When I said that every Ruby object has a class, I lied. The truth is, every object has two classes: a “regular” class and a singleton class. An object’s singleton class is a nameless class whose only instance is that object. Every object has its very own singleton class, created automatically along with the object. Singleton classes inherit from their object’s regular class and are initially empty, but you can open them up and add methods to them, which can then be called on the lone object belonging to them. This is Ruby’s secret trick to avoid “class methods” and keep its type system simple and elegant
The above passage says that Ruby's secret trick to avoid class methods. I don't understand what the author means here. Where is Ruby stopping us to avoid class methods? for an example, look at the example shown below
class Raj
def self.hi
puts 'Hi'
end
def hello
puts 'hello'
end
end
object=Raj.new
object.hello
Raj.hi
As you can see in the preceding example, the class methods can still be created.
yes?
I understand that there are no true class methods in Ruby; instead, they are methods that are created for the Raj object.
But, in any case, it's allowing me to create the method 'hi,' right?
So, what does it mean when it says, 'This is Ruby's secret trick for avoiding "class methods" and keeping its type system simple and elegant'?
I understand that there are no true class methods in Ruby; instead, they are methods that are created for the Raj object.
That's exactly it, though.
def self.hi
puts 'Hi'
end
This is not a class method or static method. Those don't exist in Ruby. That's the whole point. Your class Raj defines an object of type Class. We can see its type with the #class function.
> Raj.class
=> Class
We can also see its ancestors.
> Raj.class.ancestors
=> [Class, Module, Object, PP::ObjectMixin, Kernel, BasicObject]
Class inherits from Module, since (for the most part) classes can do everything modules can. Module, in turn, inherits from Object, which has some modules of its own mixed in (PP:ObjectMixin is for pretty-printing, and Kernel gets you the nice helpers like puts) and eventually inherits from the root class BasicObject.
But this isn't the whole story, for Raj has its own class as well: its singleton class. We can see the full story by calling #singleton_class instead of #class.
> Raj.singleton_class.ancestors
=>
[#<Class:Raj>,
#<Class:Object>,
#<Class:BasicObject>,
Class,
Module,
Object,
PP::ObjectMixin,
Kernel,
BasicObject]
Now there's a lot more going on. Raj is an instance of the singleton class of Raj, which inherits from the singleton class of Object, which in turn inherits from the singleton class of BasicObject, which inherits from Class and all of the stuff we saw before.
So when you define a method on the class Raj, you're defining it (as an instance method) on the singleton class #<Class:Raj>. And that class (currently) has one instance: Raj.
By the way, it's also useful to know that the term "singleton class" is a bit of a lie. As you can see, the class is very much not a singleton in general. For instance, the singleton class of Object, called #<Class:Object> above, actually has several instances: Object, Raj, String, and most Ruby classes. Personally, I prefer to call them eigenclasses for that reason, but "singleton class" is the official (and more well-known) term.
The author is talking about the singleton class in this sentence, there is a really nice article to deep dive into ruby singleton class: https://medium.com/#leo_hetsch/demystifying-singleton-classes-in-ruby-caf3fa4c9d91
Here is a nice example extracted from this article:
class Vehicle
def initialize(kms)
#kms = kms
end
def drive
puts "let's go!"
end
end
car = Vehicle.new(1000)
bus = Vehicle.new(3000)
def car.drive
print "I'm driving a car! "
super
end
car.drive # "I'm driving a car! let's go!"
bus.drive # "let's go!"
As you can see, here the #drive method has been overridden but only for the car object, the bus object is still using the #drive method defined in the Vehicle class.
This new method is defined on the singleton class (or shadow class) of the object, this is allowing you to define new methods on the fly on an object without polluting all the objects of this class.
This means that Ruby doesn't implement class methods.
Indeed, the Ruby OBJECT Model, allows you to "emulate" the definition of class methods by defining instance methods on the Eigenclass:
class Greeting
def self.hello
'hello world!'
end
def self.eigenclass
class << self
self
end
end
end
Greeting.eigenclass # => #<Class:Greeting>
Greeting.eigenclass.name # => nil
Greeting.singleton_methods # => [:hello, :eigenclass]
Greeting.eigenclass.instance_methods(false) # => [:hello, :eigenclass]
First, we define a Greeting.eigenclass method. This method returns self in the context of the eigenclass — by using the class << self ... end syntax. In this case, self contains an unnamed instance of the class Class (a.k.a an anonymous class). This anonymous class keeps track of the class to which it is attached — the Greeting class in our case.
Then, we can see that the singleton methods of the Greeting class are the instance methods of the Greeting eigenclass.
Feel free to have a look to this very detailed article to learn more about this concept.
To illustrate #Sébastien P.'s answer:
dice = [1,2,3,4,5,6] #an ordinary array instance
def dice.throw #now it has an extra
sample
end
p dice.throw #=>3
I've been reading my textbook, and we have come to classes and the keyword self came up. I've been reading some tutorials on tutorialpoint and have read a bunch of SO questions, but for some reason it just isn't clicking in my head Use of ruby Self, so I decided I would tinker around with some examples
Consider
class Box
# Initialize our class variables
##count = 0
def initialize(w,h)
# assign instance avriables
#width, #height = w, h
##count += 1
end
def self.printCount()
puts "Box count is : ###count"
end
end
# create two object
box1 = Box.new(10, 20)
box2 = Box.new(30, 100)
# call class method to print box count
Box.printCount()
Why will we get an error if we remove self. from our printCount() method? I know that self is important to distinguish between class variables and instance variables like in my example #width,#height and ##count.
So what I think is that since I am trying to modify the class variable ##count, I need to use the .self keyword since I am trying to modify a class variable. Thus whenever we want to change a class variable we must use the form def self.methodName.
Is my thought process correct?
There are two types of methods you are using here: instance methods and class methods. As you know, Ruby is an object oriented programming language, so everything is an object. Each object has its own methods that it can call. Let's look at your code
class Box
# Initialize our class variables
##count = 0
def initialize(w,h)
# assign instance avriables
#width, #height = w, h
##count += 1
end
def self.printCount()
puts "Box count is : ###count"
end
end
When you create a method with self.method_name, you are creating the method for the class itself. So the object of Box has a method called printCount(). That is why you can directly call the method.
Box.printCount()
However, if you declare a new instance of the class Box, calling printCount() would result in an error.
box1 = Box.new(1,1)
box1.printCount() #=> undefined method `printCount'
This is because box1 is an instance of the class Box, and the printCount method is only accessible to the class Box.
If you remove the self before the method printCount, it will become an instance method, and then box1 will have access to that method, but then the class Box will not.
And a few semantics, Ruby uses snake_case for method names, so printCount should be print_count. This is just standard practice, doesn't really affect how the code runs.
Also, you need to be careful with class variables, ie ##count. They don't behave as you would expect in Ruby. It does not just belong in the class it is declared in, it is also part of any of its descendants.
For example, let's say I define a new class call SmallBox and inherit from Box.
box1 = Box.new(1,1)
box1 = Box.new(1,1)
Now, the count should be 2 for Box. However, if you try to access the ##count from my new class,
class SmallBox < Box
p ##count
end
This would print 2 as well.
Any changes to the class variable from the descendants will change its value.
For example, I declare an instance of SmallBox, which would add 1 to ##count. You can see if you check the count in Box, it also added 1.
small1 = SmallBox.new(1,1)
class SmallBox
p ##count #=> 3
end
class Box
p ##count #=> 3
end
I would like to provide a more concrete definition which clarifies the lookup algorithm.
First, let's define self. self in Ruby is a special variable that always references the current object. The current object (self) is the default receiver on method calls. Second, self is where instance variables are found.
class MyClass
def method_one
#var = 'var'
method_two
end
def method_two
puts "#var is #{#var}"
end
end
obj = MyClass.new
obj.method_one
Above, when we call method_one, self will refer to the object instantiated, since we invoked method_one on an explicit receiver (the object instance). so self.method_one in the method definition in the Class will refer to the object instance not the Class object itself. #var will be stored in self. Note that when method_two is called, since there is no default receiver, the receiver is self. So when method_two is called, we remain in the same object instance. That is why #var in method_two will refer to the same #var in method_one. It is the same object.
Ruby supports inheritance. So if we call a method on self and it is not defined in its class, then Ruby will search for the instance method in the superclass. This happens until Ruby gets to BasicObject. If it cannot find the method in any of the superclasses, it raises a NoMethodError.
Now there is another important piece to the inheritance chain. There is an anonymous class called the singleton class that Ruby will inject into this inheritance chain. Where in the inheritance chain? It inserts it right before the original class of the object. This way, when ruby searches for the method, it will hit the singleton class before it hits the original class of the object.
> msg = 'Hello World'
=> "Hello World"
> def msg.hello_downcase
> puts 'Hello World'.downcase
> end
=> :hello_downcase
> msg.downcase
=> "hello world"
> msg2 = 'Goodbye'
=> "Goodbye"
> msg2.hellow_downcase
NoMethodError: undefined method `hellow_downcase' for "Goodbye":String
The lookup algorithm:
msg -> Anonymous Singleton Class (hello_downcase method is in here) -> String -> Object
msg2 -> String -> Object
In the above example, msg and msg2 are both object instances of the String class object. But we only opened up the singleton class of msg and not msg2. the hello_downcase method was inserted into the singleton class of msg. It's important to note that when we add another singleton method, it will reopen the same singleton class again; it will not open another anonymous singleton class. There will only be one anonymous singleton class per instance.
Notice above I said the String class object, and not just the String class. That's because a class itself is an object. A class name is simply a constant which points to an object:
class HelloWorld
def say_hi
puts 'Hello World'
end
end
More precisely, in the above example, HelloWorld is a constant which points to an object, whose class is Class. Because of this, the lookup chain will be different for HelloWorld and its instances. An instance's class is HelloWorld. And when we invoke a method with the instance as the receiver, inside HelloWorld method definitions, self will refer to that instance. Now HelloWorld's class is Class (Since Class.new is what created HelloWorld). And because of this, its inheritance chain looks different:
#<HelloWorld:0x007fa37103df38> -> HelloWorld -> Object
HelloWorld -> Class -> Module -> Object
Now since HelloWorld is also an object, just as with instances, we can open up its Singleton Class.
class HelloWorld
def self.say_hi_from_singleton_class
puts 'Hello World from the Singleton Class'
end
end
HelloWorld.say_hi_from_singleton_class
The lookup algorithm:
HelloWorld -> Anonymous Singleton Class -> Class (this is where the new method is defined) -> Module -> Object
Why does this work? As mentioned, a method call with an explicit receiver changes the value of self to point to that object. The second thing that changes the value of self is a class definition. self inside of the class definition refers to the class object, referred to by constant HelloWorld. This is only the case while inside of the class definition. Once we leave the class definition, self will no longer refer to the constant HelloWorld.
> puts self
main
> class HelloWorld
> puts self
> end
HelloWorld
=> nil
> puts self
main
Ultimately, there are two ways in which the special variable self will change: 1) when you call a method with an explicit receiver, 2) inside of a class definition.
Before I read this article, I thought access control in Ruby worked like this:
public - can be accessed by any object (e.g. Obj.new.public_method)
protected - can only be accessed from within the object itself, as well as any subclasses
private - same as protected, but the method doesn't exist in subclasses
However, it appears that protected and private act the same, except for the fact that you can't call private methods with an explicit receiver (i.e. self.protected_method works, but self.private_method doesn't).
What's the point of this? When is there a scenario when you wouldn't want your method called with an explicit receiver?
protected methods can be called by any instance of the defining class or its subclasses.
private methods can be called only from within the calling object. You cannot access another instance's private methods directly.
Here is a quick practical example:
def compare_to(x)
self.some_method <=> x.some_method
end
some_method cannot be private here. It must be protected because you need it to support explicit receivers. Your typical internal helper methods can usually be private since they never need to be called like this.
It is important to note that this is different from the way Java or C++ works. private in Ruby is similar to protected in Java/C++ in that subclasses have access to the method. In Ruby, there is no way to restrict access to a method from its subclasses like you can with private in Java.
Visibility in Ruby is largely a "recommendation" anyways since you can always gain access to a method using send:
irb(main):001:0> class A
irb(main):002:1> private
irb(main):003:1> def not_so_private_method
irb(main):004:2> puts "Hello World"
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0> foo = A.new
=> #<A:0x31688f>
irb(main):009:0> foo.send :not_so_private_method
Hello World
=> nil
The difference
Anyone can call your public methods.
You can call your protected methods, or another member of your class (or a descendant class) can call your protected methods from the outside. Nobody else can.
Only you can call your private methods, because they can only be called with an implicit receiver of self. Even you cannot call self.some_private_method; you must call private_method with self implied.
iGEL points out: "There is one exception, however. If you have a private method age=, you can (and have to) call it with self to separate it from local variables."
Since Ruby 2.7 the self receiver can be explicit, self.some_private_method is allowed. (Any other explicit receiver is still disallowed, even if the runtime value is the same as self.)
In Ruby, these distinctions are just advice from one programmer to another. Non-public methods are a way of saying "I reserve the right to change this; don't depend on it." But you still get the sharp scissors of send and can call any method you like.
A brief tutorial
# dwarf.rb
class Dwarf
include Comparable
def initialize(name, age, beard_strength)
#name = name
#age = age
#beard_strength = beard_strength
end
attr_reader :name, :age, :beard_strength
public :name
private :age
protected :beard_strength
# Comparable module will use this comparison method for >, <, ==, etc.
def <=>(other_dwarf)
# One dwarf is allowed to call this method on another
beard_strength <=> other_dwarf.beard_strength
end
def greet
"Lo, I am #{name}, and have mined these #{age} years.\
My beard is #{beard_strength} strong!"
end
def blurt
# Not allowed to do this: private methods can't have an explicit receiver
"My age is #{self.age}!"
end
end
require 'irb'; IRB.start
Then you can run ruby dwarf.rb and do this:
gloin = Dwarf.new('Gloin', 253, 7)
gimli = Dwarf.new('Gimli', 62, 9)
gloin > gimli # false
gimli > gloin # true
gimli.name # 'Gimli'
gimli.age # NoMethodError: private method `age'
called for #<Dwarf:0x007ff552140128>
gimli.beard_strength # NoMethodError: protected method `beard_strength'
called for #<Dwarf:0x007ff552140128>
gimli.greet # "Lo, I am Gimli, and have mined these 62 years.\
My beard is 9 strong!"
gimli.blurt # private method `age' called for #<Dwarf:0x007ff552140128>
Private methods in Ruby:
If a method is private in Ruby, then it cannot be called by an explicit receiver (object). It can only be call implicitly. It can be called implicitly by the class in which it has been described in as well as by the subclasses of this class.
The following examples will illustrate it better:
1) A Animal class with private method class_name
class Animal
def intro_animal
class_name
end
private
def class_name
"I am a #{self.class}"
end
end
In this case:
n = Animal.new
n.intro_animal #=>I am a Animal
n.class_name #=>error: private method `class_name' called
2) A subclass of Animal called Amphibian:
class Amphibian < Animal
def intro_amphibian
class_name
end
end
In this case:
n= Amphibian.new
n.intro_amphibian #=>I am a Amphibian
n.class_name #=>error: private method `class_name' called
As you can see, private methods can be called only implicitly. They cannot be called by explicit receivers. For the same reason, private methods cannot be called outside the hierarchy of the defining class.
Protected Methods in Ruby:
If a method is protected in Ruby, then it can be called implicitly by both the defining class and its subclasses. Additionally they can also be called by an explicit receiver as long as the receiver is self or of same class as that of self:
1) A Animal class with protected method protect_me
class Animal
def animal_call
protect_me
end
protected
def protect_me
p "protect_me called from #{self.class}"
end
end
In this case:
n= Animal.new
n.animal_call #=> protect_me called from Animal
n.protect_me #=>error: protected method `protect_me' called
2) A mammal class which is inherited from animal class
class Mammal < Animal
def mammal_call
protect_me
end
end
In this case
n= Mammal.new
n.mammal_call #=> protect_me called from Mammal
3) A amphibian class inherited from Animal class (same as mammal class)
class Amphibian < Animal
def amphi_call
Mammal.new.protect_me #Receiver same as self
self.protect_me #Receiver is self
end
end
In this case
n= Amphibian.new
n.amphi_call #=> protect_me called from Mammal
#=> protect_me called from Amphibian
4) A class called Tree
class Tree
def tree_call
Mammal.new.protect_me #Receiver is not same as self
end
end
In this case:
n= Tree.new
n.tree_call #=>error: protected method `protect_me' called for #<Mammal:0x13410c0>
Consider a private method in Java. It can be called from within the same class, of course, but it can also be called by another instance of that same class:
public class Foo {
private void myPrivateMethod() {
//stuff
}
private void anotherMethod() {
myPrivateMethod(); //calls on self, no explicit receiver
Foo foo = new Foo();
foo.myPrivateMethod(); //this works
}
}
So -- if the caller is a different instance of my same class -- my private method is actually accessible from the "outside", so to speak. This actually makes it seem not all that private.
In Ruby, on the other hand, a private method really is meant to be private only to the current instance. This is what removing the option of an explicit receiver provides.
On the other hand, I should certainly point out that it's pretty common in the Ruby community to not use these visibility controls at all, given that Ruby gives you ways to get around them anyway. Unlike in the Java world, the tendency is to make everything accessible and trust other developers not to screw things up.
What's the difference?
Private Methods Explained
#freddie = Person.new
#freddie.hows_it_going?
# => "oh dear, i'm in great pain!"
class Person
# public method
def hows_it_going?
how_are_your_underpants_feeling?
end
private
def how_are_your_underpants_feeling? # private method
puts "oh dear, i'm in great pain!"
end
end
We can ask Freddie how things are going given it's a public method. That's perfectly valid. And it's normal and accepted.
But...the only person who can know how Freddie's underpants situation is, is Freddie himself. It would not do for random strangers to reach into Freddy's underpants - no, no -- it's very, very private, and we don't want to expose what's private to the outside world. In other words, we may not want to expose mutable data, to any caller in the world. Someone could mutate a value, and we'd be in a world of pain trying to discover where the bug came from.
#freddie.how_are_your_underpants_feeling?
# => # NoMethodError: private method `how_are_your_underpants_feeling?' called
Protected Methods Explained
Consider this:
class Person
protected
def hand_over_the_credit_card! # protected method
puts "Lawd have mercy. Whatever. Here it is: 1234-4567-8910"
end
end
class Rib < Person
end
class Wife < Rib # wife inherits from Rib
def i_am_buying_another_handbag_with_your_card(husband)
husband.hand_over_the_credit_card! # equalityInAction
end
end
#husband = Person.new
#mrs = Wife.new
#mrs.i_am_buying_another_handbag_with_your_card(#husband)
# => puts "Lawd have mercy. Whatever. Here it is: 1234-4567-8910"
We're somewhat ok with mrs getting our credit card details, given mrs is flesh of our flesh, inherited from Person, so she can blow it on some shoes etc., but we don't want random individuals getting access to our credit card details.
If we tried to do that outside the subclass, it would fail:
#mrs = Wife.new
#mrs.gimme_your_credit_card!
# => protected method hand_over_the_credit_card! called for #<Wife:0x00005567b5865818> (NoMethodError)
Summary
private methods can only be called from within, and without "an explicit receiver". (Strictly speaking, you can access a private method using a little bit of ruby magic, but I'm going to ignore that for the moment).
protected methods can be called within sub-classes.
I used the examples/analogies to help you vividly remember.
Part of the reason why private methods can be accessed by subclasses in Ruby is that Ruby inheritance with classes is thin sugarcoating over Module includes - in Ruby, a class, in fact, is a kind of module that provides inheritance, etc.
http://ruby-doc.org/core-2.0.0/Class.html
What this means is that basically a subclass "includes" the parent class so that effectively the parent class's functions, including private functions, are defined in the subclass as well.
In other programming languages, calling a method involves bubbling the method name up a parent class hierarchy and finding the first parent class that responds to the method. By contrast, in Ruby, while the parent class hierarchy is still there, the parent class's methods are directly included into the list of methods of the subclass has defined.
Comparison of access controls of Java against Ruby: If method is declared private in Java, it can only be accessed by other methods within the same class. If a method is declared protected it can be accessed by other classes which exist within the same package as well as by subclasses of the class in a different package. When a method is public it is visible to everyone. In Java, access control visibility concept depends on where these classes lie's in the inheritance/package hierarchy.
Whereas in Ruby, the inheritance hierarchy or the package/module don't fit. It's all about which object is the receiver of a method.
For a private method in Ruby, it can never be called with an explicit receiver. We can (only) call the private method with an implicit receiver.
This also means we can call a private method from within a class it is declared in as well as all subclasses of this class.
class Test1
def main_method
method_private
end
private
def method_private
puts "Inside methodPrivate for #{self.class}"
end
end
class Test2 < Test1
def main_method
method_private
end
end
Test1.new.main_method
Test2.new.main_method
Inside methodPrivate for Test1
Inside methodPrivate for Test2
class Test3 < Test1
def main_method
self.method_private #We were trying to call a private method with an explicit receiver and if called in the same class with self would fail.
end
end
Test1.new.main_method
This will throw NoMethodError
You can never call the private method from outside the class hierarchy where it was defined.
Protected method can be called with an implicit receiver, as like private. In addition protected method can also be called by an explicit receiver (only) if the receiver is "self" or "an object of the same class".
class Test1
def main_method
method_protected
end
protected
def method_protected
puts "InSide method_protected for #{self.class}"
end
end
class Test2 < Test1
def main_method
method_protected # called by implicit receiver
end
end
class Test3 < Test1
def main_method
self.method_protected # called by explicit receiver "an object of the same class"
end
end
InSide method_protected for Test1
InSide method_protected for Test2
InSide method_protected for Test3
class Test4 < Test1
def main_method
Test2.new.method_protected # "Test2.new is the same type of object as self"
end
end
Test4.new.main_method
class Test5
def main_method
Test2.new.method_protected
end
end
Test5.new.main_method
This would fail as object Test5 is not subclass of Test1
Consider Public methods with maximum visibility
Summary
Public: Public methods have maximum visibility
Protected: Protected method can be called with an implicit receiver, as like private. In addition protected method can also be called by an explicit receiver (only) if the receiver is "self" or "an object of the same class".
Private: For a private method in Ruby, it can never be called with an explicit receiver. We can (only) call the private method with an implicit receiver. This also means we can call a private method from within a class it is declared in as well as all subclasses of this class.
First Three types of access specifiers and those define thier scope.
Public -> Access anywhere out side the class.
Private -> Can not access outside the class.
Protected -> This Method not access anywhere this method define
scope.
But I have a solution for this problem for all method how to access explain in depth.
class Test
attr_reader :name
def initialize(name)
#name = name
end
def add_two(number)
#number = number
end
def view_address
address("Anyaddress")
end
private
def address(add)
#add = add
end
protected
def user_name(name)
# p 'call method'
#name = name
end
end
class Result < Test
def new_user
user_name("test355")
end
end
Object List
p test = Test.new("test")
p test.name
p test.add_two(3)
List item
p test.view_address
p r = Result.new("")
p r.new_user
Im new to ruby and I am currently learning classes.
If I were to have a class
class Book
private
def BookTitle
puts "this books title"
end
end
a = Book.new
a.BookTitle
produces a NoMethodError
Is the only way I can access class methods is with this line?
attr_accessor :BookTitle
In your example, BookTitle is not defined as a class method.
To define a class method, you prefix the method name with self. (there are also other methods, though perhaps not worth worrying about for now). However, I think you are referring to instance methods rather than class methods.
You cannot directly call your BookTitle method because you have defined it as a private method. If you remove the private line in your example, you can call the method without any difficulty.
your method is private, thus you can not access it in global scope (see this irb extract):
irb(main):001:0> class Book
irb(main):002:1> private
irb(main):003:1> def BookTitle
irb(main):004:2> puts "this books title"
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0>
irb(main):008:0* a = Book.new
=> #<Book:0x105ceb8>
irb(main):009:0> a.BookTitle
NoMethodError: private method `BookTitle' called for #<Book:0x105ceb8>
from (irb):9
from D:/dev/Ruby193/bin/irb:12:in `<main>'
irb(main):010:0>
You have set BookTitle to be a private method. A private method is one that can only be called within the class itself or by instances of the class (there are exceptions). If you take the private out, it should work.
Some side notes: Ruby convention has method names as lower-case, with words separated by underscores, so you should name your method book_title.
Also, small secret, Ruby's private methods aren't so private, you could call a.send("BookTitle") and it would work.
You have set
private
on the second line which is what is preventing you from accessing this method. You could declare the method above the private line and it would be public.
Before I read this article, I thought access control in Ruby worked like this:
public - can be accessed by any object (e.g. Obj.new.public_method)
protected - can only be accessed from within the object itself, as well as any subclasses
private - same as protected, but the method doesn't exist in subclasses
However, it appears that protected and private act the same, except for the fact that you can't call private methods with an explicit receiver (i.e. self.protected_method works, but self.private_method doesn't).
What's the point of this? When is there a scenario when you wouldn't want your method called with an explicit receiver?
protected methods can be called by any instance of the defining class or its subclasses.
private methods can be called only from within the calling object. You cannot access another instance's private methods directly.
Here is a quick practical example:
def compare_to(x)
self.some_method <=> x.some_method
end
some_method cannot be private here. It must be protected because you need it to support explicit receivers. Your typical internal helper methods can usually be private since they never need to be called like this.
It is important to note that this is different from the way Java or C++ works. private in Ruby is similar to protected in Java/C++ in that subclasses have access to the method. In Ruby, there is no way to restrict access to a method from its subclasses like you can with private in Java.
Visibility in Ruby is largely a "recommendation" anyways since you can always gain access to a method using send:
irb(main):001:0> class A
irb(main):002:1> private
irb(main):003:1> def not_so_private_method
irb(main):004:2> puts "Hello World"
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0> foo = A.new
=> #<A:0x31688f>
irb(main):009:0> foo.send :not_so_private_method
Hello World
=> nil
The difference
Anyone can call your public methods.
You can call your protected methods, or another member of your class (or a descendant class) can call your protected methods from the outside. Nobody else can.
Only you can call your private methods, because they can only be called with an implicit receiver of self. Even you cannot call self.some_private_method; you must call private_method with self implied.
iGEL points out: "There is one exception, however. If you have a private method age=, you can (and have to) call it with self to separate it from local variables."
Since Ruby 2.7 the self receiver can be explicit, self.some_private_method is allowed. (Any other explicit receiver is still disallowed, even if the runtime value is the same as self.)
In Ruby, these distinctions are just advice from one programmer to another. Non-public methods are a way of saying "I reserve the right to change this; don't depend on it." But you still get the sharp scissors of send and can call any method you like.
A brief tutorial
# dwarf.rb
class Dwarf
include Comparable
def initialize(name, age, beard_strength)
#name = name
#age = age
#beard_strength = beard_strength
end
attr_reader :name, :age, :beard_strength
public :name
private :age
protected :beard_strength
# Comparable module will use this comparison method for >, <, ==, etc.
def <=>(other_dwarf)
# One dwarf is allowed to call this method on another
beard_strength <=> other_dwarf.beard_strength
end
def greet
"Lo, I am #{name}, and have mined these #{age} years.\
My beard is #{beard_strength} strong!"
end
def blurt
# Not allowed to do this: private methods can't have an explicit receiver
"My age is #{self.age}!"
end
end
require 'irb'; IRB.start
Then you can run ruby dwarf.rb and do this:
gloin = Dwarf.new('Gloin', 253, 7)
gimli = Dwarf.new('Gimli', 62, 9)
gloin > gimli # false
gimli > gloin # true
gimli.name # 'Gimli'
gimli.age # NoMethodError: private method `age'
called for #<Dwarf:0x007ff552140128>
gimli.beard_strength # NoMethodError: protected method `beard_strength'
called for #<Dwarf:0x007ff552140128>
gimli.greet # "Lo, I am Gimli, and have mined these 62 years.\
My beard is 9 strong!"
gimli.blurt # private method `age' called for #<Dwarf:0x007ff552140128>
Private methods in Ruby:
If a method is private in Ruby, then it cannot be called by an explicit receiver (object). It can only be call implicitly. It can be called implicitly by the class in which it has been described in as well as by the subclasses of this class.
The following examples will illustrate it better:
1) A Animal class with private method class_name
class Animal
def intro_animal
class_name
end
private
def class_name
"I am a #{self.class}"
end
end
In this case:
n = Animal.new
n.intro_animal #=>I am a Animal
n.class_name #=>error: private method `class_name' called
2) A subclass of Animal called Amphibian:
class Amphibian < Animal
def intro_amphibian
class_name
end
end
In this case:
n= Amphibian.new
n.intro_amphibian #=>I am a Amphibian
n.class_name #=>error: private method `class_name' called
As you can see, private methods can be called only implicitly. They cannot be called by explicit receivers. For the same reason, private methods cannot be called outside the hierarchy of the defining class.
Protected Methods in Ruby:
If a method is protected in Ruby, then it can be called implicitly by both the defining class and its subclasses. Additionally they can also be called by an explicit receiver as long as the receiver is self or of same class as that of self:
1) A Animal class with protected method protect_me
class Animal
def animal_call
protect_me
end
protected
def protect_me
p "protect_me called from #{self.class}"
end
end
In this case:
n= Animal.new
n.animal_call #=> protect_me called from Animal
n.protect_me #=>error: protected method `protect_me' called
2) A mammal class which is inherited from animal class
class Mammal < Animal
def mammal_call
protect_me
end
end
In this case
n= Mammal.new
n.mammal_call #=> protect_me called from Mammal
3) A amphibian class inherited from Animal class (same as mammal class)
class Amphibian < Animal
def amphi_call
Mammal.new.protect_me #Receiver same as self
self.protect_me #Receiver is self
end
end
In this case
n= Amphibian.new
n.amphi_call #=> protect_me called from Mammal
#=> protect_me called from Amphibian
4) A class called Tree
class Tree
def tree_call
Mammal.new.protect_me #Receiver is not same as self
end
end
In this case:
n= Tree.new
n.tree_call #=>error: protected method `protect_me' called for #<Mammal:0x13410c0>
Consider a private method in Java. It can be called from within the same class, of course, but it can also be called by another instance of that same class:
public class Foo {
private void myPrivateMethod() {
//stuff
}
private void anotherMethod() {
myPrivateMethod(); //calls on self, no explicit receiver
Foo foo = new Foo();
foo.myPrivateMethod(); //this works
}
}
So -- if the caller is a different instance of my same class -- my private method is actually accessible from the "outside", so to speak. This actually makes it seem not all that private.
In Ruby, on the other hand, a private method really is meant to be private only to the current instance. This is what removing the option of an explicit receiver provides.
On the other hand, I should certainly point out that it's pretty common in the Ruby community to not use these visibility controls at all, given that Ruby gives you ways to get around them anyway. Unlike in the Java world, the tendency is to make everything accessible and trust other developers not to screw things up.
What's the difference?
Private Methods Explained
#freddie = Person.new
#freddie.hows_it_going?
# => "oh dear, i'm in great pain!"
class Person
# public method
def hows_it_going?
how_are_your_underpants_feeling?
end
private
def how_are_your_underpants_feeling? # private method
puts "oh dear, i'm in great pain!"
end
end
We can ask Freddie how things are going given it's a public method. That's perfectly valid. And it's normal and accepted.
But...the only person who can know how Freddie's underpants situation is, is Freddie himself. It would not do for random strangers to reach into Freddy's underpants - no, no -- it's very, very private, and we don't want to expose what's private to the outside world. In other words, we may not want to expose mutable data, to any caller in the world. Someone could mutate a value, and we'd be in a world of pain trying to discover where the bug came from.
#freddie.how_are_your_underpants_feeling?
# => # NoMethodError: private method `how_are_your_underpants_feeling?' called
Protected Methods Explained
Consider this:
class Person
protected
def hand_over_the_credit_card! # protected method
puts "Lawd have mercy. Whatever. Here it is: 1234-4567-8910"
end
end
class Rib < Person
end
class Wife < Rib # wife inherits from Rib
def i_am_buying_another_handbag_with_your_card(husband)
husband.hand_over_the_credit_card! # equalityInAction
end
end
#husband = Person.new
#mrs = Wife.new
#mrs.i_am_buying_another_handbag_with_your_card(#husband)
# => puts "Lawd have mercy. Whatever. Here it is: 1234-4567-8910"
We're somewhat ok with mrs getting our credit card details, given mrs is flesh of our flesh, inherited from Person, so she can blow it on some shoes etc., but we don't want random individuals getting access to our credit card details.
If we tried to do that outside the subclass, it would fail:
#mrs = Wife.new
#mrs.gimme_your_credit_card!
# => protected method hand_over_the_credit_card! called for #<Wife:0x00005567b5865818> (NoMethodError)
Summary
private methods can only be called from within, and without "an explicit receiver". (Strictly speaking, you can access a private method using a little bit of ruby magic, but I'm going to ignore that for the moment).
protected methods can be called within sub-classes.
I used the examples/analogies to help you vividly remember.
Part of the reason why private methods can be accessed by subclasses in Ruby is that Ruby inheritance with classes is thin sugarcoating over Module includes - in Ruby, a class, in fact, is a kind of module that provides inheritance, etc.
http://ruby-doc.org/core-2.0.0/Class.html
What this means is that basically a subclass "includes" the parent class so that effectively the parent class's functions, including private functions, are defined in the subclass as well.
In other programming languages, calling a method involves bubbling the method name up a parent class hierarchy and finding the first parent class that responds to the method. By contrast, in Ruby, while the parent class hierarchy is still there, the parent class's methods are directly included into the list of methods of the subclass has defined.
Comparison of access controls of Java against Ruby: If method is declared private in Java, it can only be accessed by other methods within the same class. If a method is declared protected it can be accessed by other classes which exist within the same package as well as by subclasses of the class in a different package. When a method is public it is visible to everyone. In Java, access control visibility concept depends on where these classes lie's in the inheritance/package hierarchy.
Whereas in Ruby, the inheritance hierarchy or the package/module don't fit. It's all about which object is the receiver of a method.
For a private method in Ruby, it can never be called with an explicit receiver. We can (only) call the private method with an implicit receiver.
This also means we can call a private method from within a class it is declared in as well as all subclasses of this class.
class Test1
def main_method
method_private
end
private
def method_private
puts "Inside methodPrivate for #{self.class}"
end
end
class Test2 < Test1
def main_method
method_private
end
end
Test1.new.main_method
Test2.new.main_method
Inside methodPrivate for Test1
Inside methodPrivate for Test2
class Test3 < Test1
def main_method
self.method_private #We were trying to call a private method with an explicit receiver and if called in the same class with self would fail.
end
end
Test1.new.main_method
This will throw NoMethodError
You can never call the private method from outside the class hierarchy where it was defined.
Protected method can be called with an implicit receiver, as like private. In addition protected method can also be called by an explicit receiver (only) if the receiver is "self" or "an object of the same class".
class Test1
def main_method
method_protected
end
protected
def method_protected
puts "InSide method_protected for #{self.class}"
end
end
class Test2 < Test1
def main_method
method_protected # called by implicit receiver
end
end
class Test3 < Test1
def main_method
self.method_protected # called by explicit receiver "an object of the same class"
end
end
InSide method_protected for Test1
InSide method_protected for Test2
InSide method_protected for Test3
class Test4 < Test1
def main_method
Test2.new.method_protected # "Test2.new is the same type of object as self"
end
end
Test4.new.main_method
class Test5
def main_method
Test2.new.method_protected
end
end
Test5.new.main_method
This would fail as object Test5 is not subclass of Test1
Consider Public methods with maximum visibility
Summary
Public: Public methods have maximum visibility
Protected: Protected method can be called with an implicit receiver, as like private. In addition protected method can also be called by an explicit receiver (only) if the receiver is "self" or "an object of the same class".
Private: For a private method in Ruby, it can never be called with an explicit receiver. We can (only) call the private method with an implicit receiver. This also means we can call a private method from within a class it is declared in as well as all subclasses of this class.
First Three types of access specifiers and those define thier scope.
Public -> Access anywhere out side the class.
Private -> Can not access outside the class.
Protected -> This Method not access anywhere this method define
scope.
But I have a solution for this problem for all method how to access explain in depth.
class Test
attr_reader :name
def initialize(name)
#name = name
end
def add_two(number)
#number = number
end
def view_address
address("Anyaddress")
end
private
def address(add)
#add = add
end
protected
def user_name(name)
# p 'call method'
#name = name
end
end
class Result < Test
def new_user
user_name("test355")
end
end
Object List
p test = Test.new("test")
p test.name
p test.add_two(3)
List item
p test.view_address
p r = Result.new("")
p r.new_user