2. public class Cat {
public static int getNumLegs() {
return 4;
}
public void eat() {
System.out.println("om nom nom");
}
public static void main(String[] args) {
Cat happyCat = new Cat();
happyCat.eat();
}
}
16. class C; end
C.class_eval do
def d
puts "d"
end
end
C.d
C.new.d
class C; end
C.instance_eval do
def d
puts "d"
end
end
C.d
C.new.d
Notas del editor
since this is a talk about ruby, what better way to start than...
# okay, if your first language was Java like mine was, you know what a class method is and what an instance method is. Class or static methods are called on the class, instance methods are called on instances. A method can be either class or instance but not both. Well, Ruby went and turned that upside down. I'm sure you've been told 100 times that everything in Ruby is an object, and that goes for classes too. They're instances of the class Class. That's easy enough to follow until someone goes, so is a method defined on a class a class method or an instance method?
# so you see, if you think of class and instance methods as a dichotomy, you'll get lost pretty quickly. they're not mutually exclusive in Ruby; class methods are a subset of instance methods. so how are class methods different? the difference is that while instance methods apply to all instances of the class they're defined on, class methods only apply to the instance of the class Class that they're defined on. wait what? say that again? it turns out that yes, you can define classes on a single instance of a class, a single object, and only that object would have that method. But since every method needs to belong to a class, ruby calls that class the object's singleton class. basically, every object in Ruby walks around with this singleton class shadowing it. thanks to singleton classes, you can do things like this:
# doing this does not affect the general cat species
# which btw you can also do like this
# this angled brackets syntax opens up a new scope where the 'self' object becomes happy_cat inside the block.
# you've probably seen the angled brackets syntax used like this
remember those weird class methods? Remember how classes are just instances of the class Class? now you know how it's done.
# self is Cat, so you're defining this method on Cat only
now that we know about singleton classes, i want to add a note about how ruby resolves redefined methods.
also note that the way ruby's method resolution works is that each time you redefine a method, it gets inserted into the method lookup chain such that methods defined on singleton classes will resolve first, followed by included modules from bottom to top (i think of it as the methods overwriting each other), and finally the superclass. and as you may have also heard, when it comes to code reuse, rubyists prefer mixins to subclassing, so when you're reading code and something calls 'super' it's actually more likely to go to an included module than a superclass.
# now armed with our knowledge of singleton classes, we come to an area that has stirred up much confusion. you know modules can be added to classes with include and extend. but how are they different?
# You may also have seen modules being extended
# The oft cited distinction is that 'include creates instance methods, extend create class methods'. okay, so if i wanted a particular cat to bark, since i'm defining an instance method, i'd do this right?
# guess what that gives us
apparently include isn't an Object method. but if you do this on the other hand
a quick check with the ruby api confirms that
extend is an Object method
whereas include is a Module method and so can only be called on module and classes (which are subclasses of Module).
things become clearer if we ditch the class method/instance method distinction and only differentiate methods based on whether they belong to singleton or regular classes (which conveniently is how the creators of Ruby see things). so, include is defined on modules and classes and creates regular-class methods, whereas extend is defined on all objects and creates singleton, object-level methods.
looking at things this way also helps with distinguishing between another pair of confusing methods, class_eval and instance_eval. Both take a block of code and execute it.
an uninitiated person would assume class_eval creates class methods and instance_eval creates instance methods. but the present company know that as far as the creators of ruby are concerned, there's no such thing as a class method. but guess what sort of thing class_eval is defined on? that's right, classes. and what sort of thing is instance_eval defined on? instances of classes, also known as objects. those methods are named after their receivers and the context they run the block in, not what they create.
so with that in mind, let’s walk through both of these chunks of code. the one on the left evaluates d in the context of the class C, so d should end up being an instance method. so C.d should raise a no method error and c.new.d should print d.
the one on the right evaluates d in the context of the object C, so d should be a singleton method that only belongs to C, so C.d should print d and C.new.d should raise a no method error.
let’s try it out (remember to kill irb between runs)
that concludes my rambling talk. i hope i’ve made the way method definitions work in ruby a little clearer to you.