THE RUBY WAY, Third Edition (2015)

---

Here, we open up the singleton class and define an accessor called home_planet. The two child classes call their own accessors and set the variable. These accessors work strictly on a per-class basis now.

As a small enhancement, let’s also add a private call in the singleton class:

private :home_planet=

Making the writer private will prevent any code outside the hierarchy from changing this value. As always, using private is an “advisory” protection and is easily bypassed by the programmer who wants to. Making a method private at least tells us we are not meant to call that method in this particular context.

I should mention that there are other ways of implementing these techniques. Use your creativity.

11.2.5 Storing Code as Proc Objects

Not surprisingly, Ruby gives you several alternatives when it comes to storing a chunk of code in the form of an object. We’ll take a look at Proc objects and lambdas here.

The built-in class Proc represents a Ruby block as an object. Proc objects, like blocks, are closures and therefore carry around the context where they were defined. The proc method is a shorthand alias for Proc.new.

local = 12
myproc = Proc.new {|a| puts "Param is #{a}, local is #{local}" }
myproc.call(99) # Param is 99, local is 12

Proc objects are also created automatically by Ruby when a method defined with a trailing & parameter is called with a block:

def take_block(x, &block)
puts block.class
x.times {|i| block[i, i*i] }
end

take_block(3) { |n,s| puts "#{n} squared is #{s}" }

This example also shows the use of brackets ([]) as an alias for the call method. The output is shown here:

Proc
0 squared is 0
1 squared is 1
2 squared is 4

If you have a Proc object, you can pass it to a method that’s expecting a block, preceding its name with an &, as shown here:

myproc = proc { |n| print n, "... " }
(1..3).each(&myproc) # 1... 2... 3...

Although it can certainly be useful to pass a Proc to a method, calling return from inside the Proc returns from the entire method. A special type of Proc object, called a lamdba, returns only from the block:

def greet(&block)
block.call
"Good morning, everyone."
end

philippe_proc = Proc.new { return "Too soon, Philippe!" }
philippe_lambda = lambda { return "Too soon, Philippe!" }

p greet(philippe_proc) # Too soon, Philippe!
p greet(philippe_lambda) # Good morning, everyone.

In addition to the keyword lambda, the -> notation also creates lambdas. Just keep in mind that -> (sometimes called “stabby proc” or “stabby lambda”) puts block arguments outside the curly braces:

non_stabby_lambda = lambda {|king| greet(king) }
stabby_lambda = -> (king) { stab(king) }

11.2.6 Storing Code as Method Objects

Ruby also lets you turn a method into an object directly using Object#method. The method method returns a Method object, which is a closure that is bound to the object it was created from:

str = "cat"
meth = str.method(:length)

a = meth.call # 3 (length of "cat")
str << "erpillar"
b = meth.call # 11 (length of "caterpillar")

str = "dog"
c = meth.call # 11 (length of "caterpillar")

Note the final call! The variable str refers to a new object ("dog") now, but meth is still bound to the old object.

A call to public_method works the same way, but as the name implies, it only searches public methods on the receiver.

To get a method that can be used with any instance of a particular class, you can use instance_method to create UnboundMethod objects. Before calling an UnboundMethod object, you must first bind it to a particular object. This act of binding produces a Method object, which you call normally:

umeth = String.instance_method(:length)

m1 = umeth.bind("cat")
m1.call # 3

m2 = umeth.bind("caterpillar")
m2.call # 11

Binding a method to the wrong class can cause an error, but allowing binding to other objects makes UnboundMethod a little more intuitive than Method.

11.2.7 Using Symbols as Blocks

When a parameter is prefixed with an ampersand, it is treated by Ruby as a block parameter. As shown earlier, it is possible to create a Proc object, assign it to a variable, and then use that Proc as the block for a method that takes a block.

However, as mentioned in Section 11.2.1, “Sending an Explicit Message to an Object,” it is possible to call methods that require blocks but only pass them a symbol prefixed by an ampersand. Why is that possible? The answer lies in the to_proc method.

A non-obvious side effect of providing a block parameter as an argument is that if the argument is not a Proc, Ruby will attempt to convert it into one by calling to_proc on it.

Some clever Ruby developers realized that this could be leveraged to simplify their calls to map, and they defined the to_proc method on the Symbol class. The implementation looks something like this:

class Symbol
def to_proc
Proc.new {|obj| obj.send(self) }
end
end

# Which allows map to be invoked like this:
%w[A B C].map(&:chr) # [65, 66, 67]

This shortcut proved to be so popular that it was added to Ruby itself, and can now be used anywhere.

11.2.8 How Module Inclusion Works

When a module is included into a class, Ruby in effect creates a proxy class as the immediate ancestor of that class. You may or may not find this intuitive. Any methods in an included module are “masked” by any methods that appear in the class:

module MyMod
def meth
"from module"
end
end

class ParentClass
def meth
"from parent"
end
end

class ChildClass < ParentClass
def meth
"from child"
end
include MyMod
end

x = ChildClass.new
p x.meth # from child

This is just like a regular inheritance relationship: Anything the child redefines is the new current definition. This is true regardless of whether the include is done before or after the redefinition.

Here’s a similar example, where the child method invokes super instead of returning a simple string. What do you expect it to return?

# MyMod and ParentClass unchanged
class ChildClass < ParentClass
include MyMod
def meth
"from child: super = " + super
end
end

x = ChildClass.new
p x.meth # from child: super = from module

As you can see, MyMod is really the new parent of ChildClass. What if we also let the module invoke super in the same way?

module MyMod
def meth
"from module: super " + super
end
end

# ParentClass is unchanged

class ChildClass < ParentClass
include MyMod
def meth
"from child: super " + super
end
end

x = ChildClass.new
p x.meth # from child: super from module: super from parent

Modules have one more trick up their sleeve, though, in the form of the prepend method. It allows a module method to be inserted beneath the method of the including class:

# MyMod and ParentClass unchanged

class ChildClass < ParentClass
prepend MyMod
def meth
"from child: super " + super
end
end

x = ChildClass.new
p x.meth # from module: super from child: super from parent

This feature of Ruby allows modules to alter the behavior of methods even when the method in the child class does not call super.

Whether included or prepended, the meth from MyMod can call super only because there actually is a meth in the superclass (that is, in at least one ancestor). What would happen if we called this in another circumstance?

module MyMod
def meth
"from module: super = " + super
end
end

class Foo
include MyMod
end

x = Foo.new
x.meth

This code would result in a NoMethodError (or a call to method_missing, if it had been defined).

11.2.9 Detecting Default Parameters

The following question was once asked by Ian Macdonald on the Ruby mailing list: “How can I detect whether a parameter was specified by the caller, or the default was taken?” This is an interesting question; not something you would use every day, but still interesting.

At least three solutions were suggested. By far the simplest and best was by Nobu Nakada, which is shown in the following code:

def meth(a, b=(flag=true; 345))
puts "b is #{b} and flag is #{flag.inspect}"
end

meth(123) # b is 345 and flag is true
meth(123,345) # b is 345 and flag is nil
meth(123,456) # b is 456 and flag is nil

As the preceding example shows, this trick works even if the caller explicitly supplies what happens to be the default value. The trick is obvious when you see it: The parenthesized expression sets a local variable called flag but then returns the default value 345. This solution is a tribute to the power of Ruby.

11.2.10 Delegating or Forwarding

Ruby has two libraries that offer solutions for delegating or forwarding method calls from the receiver to another object. These are delegate and forwardable; we’ll look at them in that order.

The delegate library gives you three ways of solving this problem.

The SimpleDelegator class can be useful when the object delegated to can change over the lifespan of the receiving object. The __setobj__ method is used to select the object to which you’re delegating.

However, I find the SimpleDelegator technique to be a little too simple. Because I am not convinced it offers a significant improvement over doing the same thing by hand, I won’t cover it here.

The DelegateClass top-level method takes a class (to be delegated to) as a parameter. It then creates a new class from which we can inherit. Here’s an example of creating our own Queue class that delegates to an Array object:

require 'delegate'
class MyQueue < DelegateClass(Array)

def initialize(arg=[])
super(arg)
end

alias_method :enqueue, :push
alias_method :dequeue, :shift
end

mq = MyQueue.new

mq.enqueue(123)
mq.enqueue(234)


p mq.dequeue # 123
p mq.dequeue # 234

It’s also possible to inherit from Delegator and implement a __getobj__ method; this is the way SimpleDelegator is implemented, and it offers more control over the delegation.

However, if you want more control, you should probably be doing per-method delegation rather than per-class anyway. The forwardable library enables you to do this. Let’s revisit the queue example:

require 'forwardable'

class MyQueue
extend Forwardable

def initialize(obj=[])
@queue = obj # delegate to this object
end

def_delegator :@queue, :push, :enqueue
def_delegator :@queue, :shift, :dequeue

def_delegators :@queue, :clear, :empty?, :length, :size, :<<

# Any additional stuff...
end

This example shows that the def_delegator method associates a method call (for example, enqueue) with a delegated object @queue and the correct method to call on that object (push). In other words, when we call enqueue on a MyQueue object, we delegate that by making apush call on our object @queue (which is usually an array).

Notice that we say :@queue rather than :queue or @queue; this is simply because of the way the Forwardable class is written. It could have been done differently.

Sometimes we want to pass methods through to the delegate object by using the same method name. The def_delegators method allows us to specify an unlimited number of these. For example, as shown in the preceding code example, invoking length on a MyQueue object will in turn call length on @queue.

Unlike the first example in this chapter, the other methods on the delegate object are simply not supported. This can be a good thing. For example, you don’t want to invoke [] or []= on a queue; if you do, you’re not using it as a queue anymore.

Also notice that the previous code allows the caller to pass an object into the constructor (to be used as the delegate object). In the spirit of duck-typing, this means that we can choose the kind of object we want to delegate to—as long as it supports the set of methods that we reference in the code.

For example, the following calls are all valid (note that the last two assume that we’ve done a require 'thread' previously):

q1 = MyQueue.new # use an array
q2 = MyQueue.new(my_array) # use one specific array
q3 = MyQueue.new(Queue.new) # use a Queue (thread.rb)
q4 = MyQueue.new(SizedQueue.new) # use a SizedQueue (thread.rb)

So, for example, q3 and q4 in the preceding examples are now magically thread-safe because they delegate to an object that is thread-safe. (That’s unless any customized code not shown here violates that.)

There is also a SingleForwardable class that operates on an instance rather than on an entire class. This is useful if you want just one instance of a class to delegate to another object, while all other instances continue to not delegate, as before.

One final option is manual delegation. Ruby makes it extremely straightforward to simply wrap one object in another, which is another way to implement our queue:

class MyQueue
def initialize(obj=[])
@queue = obj # delegate to this object
end

def enqueue(arg)
@queue.push(arg)
end

def dequeue(arg)
@queue.shift(arg)
end

%i[clear empty? length size <<].each do |name|
define_method(name){|*args| @queue.send(name, *args) }
end

# Any additional stuff...
end

As you can see, in some cases, it may not be a noticeable advantage to use a library for delegation instead of writing some simple code.

You might ask, “Is delegation better than inheritance?” But that’s the wrong question in a sense. Sometimes the situation calls for delegation rather than inheritance; for example, suppose that a class already has a parent class. We can still use delegation (in some form), but we can’t inherit from an additional parent (because Ruby doesn’t allow multiple inheritance).

11.2.11 Defining Class-Level Readers and Writers

We have seen the methods attr_reader, attr_writer, and attr_accessor, which make it a little easier to define readers and writers (getters and setters) for instance attributes. But what about class-level attributes?

Ruby has no similar facility for creating these automatically. However, we could create something similar on our own very simply. Just open the singleton class and use the ordinary attr family of methods.

The resulting instance variables in the singleton class will be class instance variables. These are often better for our purposes than class variables because they are strictly “per class” and are not shared up and down the hierarchy.

class MyClass
@alpha = 123 # Initialize @alpha

class << self
attr_reader :alpha # MyClass.alpha()
attr_writer :beta # MyClass.beta=()
attr_accessor :gamma # MyClass.gamma() and MyClass.gamma=()
end

def MyClass.look
puts "#@alpha, #@beta, #@gamma"
end

#...
end


puts MyClass.alpha # 123
MyClass.beta = 456
MyClass.gamma = 789
puts MyClass.gamma # 789

MyClass.look # 123, 456, 789

Most classes are no good without instance level data as well, but we’ve omitted it here for clarity.

11.2.12 Working in Advanced Programming Disciplines

Brother, can you paradigm?

—Graffiti seen at IBM Austin, 1989

Many philosophies of programming are popular in various circles. These are often difficult to characterize in relation to object-oriented or dynamic techniques, and some of these styles can actually be independent of whether a language is dynamic or object oriented.

Because we are far from experts in these matters, we are relying mostly on hearsay. So take these next paragraphs with a grain of sodium chloride.

Some programmers prefer a flavor of OOP known as prototype-based OOP (or classless OOP). In this world, an object isn’t described as a member of a class; it is built from the ground up, and other objects are created based on the prototype. Ruby has at least rudimentary support for this programming style because it allows singleton methods for individual objects, and the clone method will clone these singletons. Interested readers should also look at the simple OpenStruct class for building Python-like objects; you should also be aware of how method_missingworks.

One or two limitations in Ruby hamper classless OOP. Certain objects such as Fixnums are stored not as references but as immediate values so that they can’t have singleton methods. This is supposed to change in the future, but at the time of this writing, it’s impossible to project when it will happen.

In functional programming (FP), emphasis is placed on the evaluation of expressions rather than the execution of commands. An FP language is one that encourages and supports functional programming, and as such, there is a natural gray area. Nearly all would agree that Haskell is a pure functional language, whereas Ruby certainly isn’t one.

But Ruby has at least some minimal support for FP; it has a fairly rich set of methods for operating on arrays (lists), and it has Proc objects so that code can be encapsulated and called over and over. Ruby allows the method chaining that is so common in FP. There have been some initial efforts at creating a library that would serve as a kind of FP “compatibility layer,” borrowing certain ideas from Haskell. At the time of this writing, these efforts aren’t complete.

The concept of aspect-oriented programming (AOP) is an interesting one. In AOP, programmers to deal with programming issues that crosscut the modular structure of the program. In other words, some activities or features of a system will be scattered across the system in code fragments here and there, rather than being gathered into one tidy location. AOP can modularize things that are difficult to modularize using traditional OOP or procedural techniques. It works at right angles to the usual way of thinking.

Ruby certainly wasn’t created specifically with AOP in mind. However, it was designed to be a flexible and dynamic language, and it is conceivable that these techniques can be facilitated by a library. The Module#prepend method and the aspector gem both provide some amount of AOP within Ruby.

The concept of design by contract (DBC) is well known to Eiffel devotees, although it is certainly known outside those circles also. The general idea is that a piece of code (a method or class) implements a contract; certain preconditions must be true if the code is going to do its job, and the code guarantees that certain post-conditions are true afterward. The robustness of a system can be greatly enhanced by the ability to specify this contract explicitly and have it automatically checked at runtime. The usefulness of the technique is expanded by the inheritance of contract information as classes are extended.

The Eiffel language had DBC explicitly built in; Ruby does not. There are usable implementations of DBC libraries, however, and they are worth investigating.

Design patterns have inspired much discussion over the last few years. These, of course, are highly language independent and can be implemented well in many languages. But again, Ruby’s unusual flexibility makes them perhaps more practical than in some other environments. Well-known examples of these are given elsewhere; the Visitor pattern is essentially implemented in Ruby’s default iterator each, and other patterns are part of Ruby’s standard distribution (such as the standard libraries delegator and singleton).

We don’t use the term “Extreme Programming” (XP) anymore, but many of its principles are ingrained in our culture by now. This methodology encourages (among other things) early testing and refactoring on the fly.

The “culture of testing” isn’t language specific, although it might be easier in some languages than others. Certainly we maintain that Ruby makes (manual) refactoring easier than many languages would, although that is a highly subjective claim. However, the existence of the RSpeclibrary (and others) makes for a real blending of Ruby and XP. This library facilitates unit testing; it is powerful, easy to use, and has proven useful in developing much other Ruby software in current use. We highly recommend the practice of testing early and often, and we recommendRSpec for those who want to do this in Ruby. (Minitest is another excellent gem, for those who prefer the Test::Unit style.)

By the time you read this, many of the issues we talk about in this section will have been fleshed out more. As always, your best resources for the latest information are online. It’s difficult to list online resources in print because they are in constant flux. In this case, the search engine is your friend.

11.3 Working with Dynamic Features

Skynet became self-aware at 2:14 a.m. EDT August 29, 1997.

—Terminator 2: Judgment Day

Some of you may come from the background of a static language such as C. To those readers, we will address this rhetorical question: Can you imagine writing a C function that will take a string, treat it as a variable name, and return the value of the variable? No? Then can you imagine removing or replacing the definition of a function? Can you imagine trapping calls to nonexistent functions?

Ruby makes this sort of thing possible. These capabilities take getting used to, and they are easy to abuse. However, the concepts have been around for many years (they are at least as old as LISP) and are regarded as “tried and true” in the Scheme and Smalltalk communities as well. Python has many dynamic features, and even Java has some dynamic features, so we expect this way of thinking to continue to increase in popularity over time.

11.3.1 Evaluating Code Dynamically

The global function eval compiles and executes a string that contains a fragment of Ruby code. This is a powerful (albeit extremely dangerous) mechanism, because it allows you to build up code to be executed at runtime. For example, the following code reads in lines of the form “name = expression.” It then evaluates each expression and stores the result in a hash indexed by the corresponding variable name:

parameters = {}

ARGF.each do |line|
name, expr = line.split(/\s*=\s*/, 2)
parameters[name] = eval expr
end

Suppose the input contained these lines:

a = 1
b = 2 + 3
c = 'date'

Then the hash parameters would end up with the value {"a"=>1, "b"=>5, "c"=>"Sat Jul 26 00:51:48 PDT 2014\n"}. This example also illustrates the danger of evaling strings when you don’t control their contents; a malicious user could put d=`rm *` in the input and ruin your day.

Ruby has three other methods that evaluate code “on the fly”: class_eval, module_eval, and instance_eval. The first two are synonyms, and all three do effectively the same thing; they evaluate a string or a block, but while doing so they change the value of self to their own receiver. Perhaps the most common use of class_eval allows you to add methods to a class when all you have is a reference to that class.

We use this in the hook_method code in the Trace example in Section 11.4.3, “Tracking Changes to a Class or Object Definition.” You’ll find other examples in the more dynamic library modules, such as the standard library delegate.rb.

The eval method also makes it possible to evaluate local variables in a context outside their scope. We don’t advise doing this lightly, but it’s nice to have the capability.

Ruby associates local variables with blocks, with high-level definition constructs (class, module, and method definitions), and with the top-level of your program (the code outside any definition constructs). Associated with each of these scopes is the binding of variables, along with other housekeeping details.

Probably the ultimate user of bindings is pry, an interactive Ruby console. It not only uses bindings to keep the variables in the program that you type in separate from its own, but adds the Binding#pry method to open a new interactive console within that binding. We’ll look more closely at pry in Chapter 16, “Testing and Debugging.”

You can encapsulate the current binding in an object using the method Kernel#binding. Having done that, you can pass the binding as the second parameter to eval, setting the execution context for the code being evaluated.

def some_method
a = "local variable"
return binding
end

the_binding = some_method
eval "a", the_binding # "local variable"

Interestingly, the presence of a block associated with a method is stored as part of the binding, enabling tricks such as this:

def some_method
return binding
end

the_binding = some_method { puts "hello" }
eval "yield", the_binding # hello

11.3.2 Retrieving a Constant by Name

The const_get method retrieves the value of a constant (by name) from the module or class to which it belongs:

str = "PI"
Math.const_get(str) # Evaluates to Math::PI

This is a way of avoiding the use of eval, which is both dangerous and considered inelegant. This type of solution is better code, it’s computationally cheaper, and it’s safer. Other similar methods are instance_variable_set, instance_variable_get, anddefine_method.

It’s true that const_get is faster than eval. In informal tests, const_get was roughly 350% as fast; your results will vary. But is this really significant? The fact is, the test code ran a loop 10 million times to get good results and still finished in under 30 seconds.

The usefulness of const_get is that it is easier to read, more specific, and more self-documenting. This is the real reason to use it. In fact, even if it did not exist, to make it a synonym for eval might still be a step forward.

See also the next section (11.3.3, “Retrieving a Class by Name”) for another trick.

11.3.3 Retrieving a Class by Name

We have seen this question more than once. Given a string containing the name of a class, how can we create an instance of that class?

Classes in Ruby are normally named as constants in the “global” namespace—that is, members of Object. That means the proper way is with const_get, which we just saw:

classname = "Array"
klass = Object.const_get(classname)
x = klass.new(4, 1) # [1, 1, 1, 1]

If the constant is inside a namespace, just provide a string that with namespaces delimited by two colons (as if you were writing Ruby directly):

class Alpha
class Beta
class Gamma
FOOBAR = 237
end
end
end

str = "Alpha::Beta::Gamma::FOOBAR"
val = Object.const_get(str) # 237

11.3.4 Using define_method

Other than def, define_method is the only normal way to add a method to a class or object; the latter, however, enables you to do it at runtime.

Of course, essentially everything in Ruby happens at runtime. If you surround a method definition with puts calls, as in the following example, you can see that:

class MyClass
puts "before"


def meth
#...
end


puts "after"
end

However, within a method body or similar place, we can’t just reopen a class (unless it’s a singleton class). In such a case, we use define_method. It takes a symbol (for the name of the method) and a block (for the body of the method):

if today =~ /Saturday|Sunday/
define_method(:activity) { puts "Playing!" }
else
define_method(:activity) { puts "Working!" }
end

activity

Note, however, that define_method is private. This means that calling it from inside a class definition or method will work just fine, as shown here:

class MyClass
define_method(:body_method) { puts "The class body." }

def self.new_method(name, &block)
define_method(name, &block)
end
end

MyClass.new_method(:class_method) { puts "A class method." }

x = MyClass.new
x.body_method # Prints "The class body."
x.class_method # Prints "A class method."

We can even create an instance method that dynamically defines other instance methods:

class MyClass
def new_method(name, &block)
self.class.send(:define_method, name, &block)
end
end


x = MyClass.new
x.new_method(:instance_method) { puts "An instance method." }
x.mymeth # Prints "An instance method."

Here, we’re still defining an instance method dynamically. Only the means of invoking new_method has changed. Note the send trick that we use to circumvent the privacy of define_method. This works because send always allows you to call private methods. (This is another “loophole,” as some would call it, that has to be used responsibly.)

It’s important to realize another fact about define_method: It takes a block, and a block in Ruby is a closure. This means that, unlike an ordinary method definition, we are capturing context when we define the method. The following example is useless, but it illustrates the point:

class MyClass
def self.new_method(name, &block)
define_method(name, &block)
end
end

a, b = 3, 79
MyClass.new_method(:compute) { a*b }

x = MyClass.new
puts x.compute # 237

a, b = 23, 24
puts x.compute # 552

The point is that the new method can access variables in the original scope of the block, even if that scope “goes away” and is otherwise inaccessible. This will be useful at times, perhaps in a metaprogramming situation or with a GUI toolkit that allows defining methods for event callbacks.

Note that the closure only has access to variables with the same names. On rare occasions, this can be tricky. Here, we use define to expose a class variable (not really the way we should do it, but it illustrates the point):

class SomeClass
@@var = 999

define_method(:peek) { @@var }
end

x = SomeClass.new
p x.peek # 999

Now let’s try this with a class instance variable:

class SomeClass
@var = 999

define_method(:peek) { @var }
end

x = SomeClass.new
p x.peek # prints nil

We expect 999 but get nil instead. Observe, on the other hand, that the following works fine:

class SomeClass
@var = 999
x = @var

define_method(:peek) { x }
end

x = SomeClass.new
p x.peek # 999

So what is happening? Well, it is true that a closure captures the variables from its context. But even though a closure knows the variables from its scope, the method context is the context of the instance, not the class itself.

Because @var in the instance context would refer to an instance variable of the object, the class instance variable is hidden by the object’s instance variable—even though it has never been used and technically doesn’t exist.

When working with individual objects, define_singleton_method is a convenient alternative to opening the singleton class and defining a method. It works analogously to define_method.

Although you can define methods at runtime by calling eval, avoid doing this. Instead, define_method can and should be used in all these circumstances. Minor subtleties like those just mentioned shouldn’t deter you.

11.3.5 Obtaining Lists of Defined Entities

The reflection API of Ruby enables us to examine the classes and objects in our environment at runtime. We’ll look at methods defined in Module, Class, and Object.

The Module module has a method named constants that returns an array of all the constants in the system (including class and module names). The nesting method returns an array of all the modules nested at the current location in the code.

The instance method Module#ancestors returns an array of all the ancestors of the specified class or module:

list = Array.ancestors # [Array, Enumerable, Object,
Kernel, BasicObject]

The constants method lists all the constants accessible in the specified module. Any ancestor modules are included:

list = Math.constants # [:DomainError, :PI, :E]

The class_variables method returns a list of all class variables in the given class and its superclasses. The included_modules method lists the modules included in a class:

class Parent
@@var1 = nil
end

class Child < Parent
@@var2 = nil
end

list1 = Parent.class_variables # [:@@var1]
list2 = Array.included_modules # [Enumerable, Kernel]

The Class methods instance_methods and public_instance_methods are synonyms; they return a list of the public instance methods for a class. The methods private_instance_methods and protected_instance_methods behave as expected. Any of these can take a Boolean parameter, which defaults to true; if it is set to false, superclasses will not be searched, thus resulting in a smaller list:

n1 = Array.instance_methods.size # 174
n2 = Array.public_instance_methods.size # 174
n3 = Array.public_instance_methods(false).size # 90
n4 = Array.private_instance_methods.size # 84
n5 = Array.protected_instance_methods.size # 0

The Object class has a number of similar methods that operate on instances (see Listing 11.15). Calling methods will return a list of all methods that can be invoked on that object. Calling public_methods will return a list of publicly accessible methods; this takes a parameter, defaulting to true, to choose whether methods from superclasses are included. The methods private_methods, protected_methods, and singleton_methods all take a similar parameter, and they return the methods you would expect them to return.

Listing 11.15 Reflection and Instance Variables