Errata for Metaprogramming Ruby

#45084: From Kado: a comment about "private" on the book:

there is one exception: it's "setter" method.
"setter" always need "self" as literal.

def setter=(val)
 p val
end
private :Setter=

def getter
 p 123
end
private :getter

self.setter=(123) # => 123
self.getter       # => NoMethodError--Paolo Perrotta

#49692: Mention (from the BasicObject documentation):
"BasicObject does not include Kernel (for methods like puts) and BasicObject is outside of the namespace of the standard library so common classes will not be found without a using a full class path. ... Access to classes and modules from the Ruby standard library can be obtained in a BasicObject subclass by referencing the desired constant from the root like ::File or ::Enumerator."--Paolo Perrotta

#48047: (from @jonclaus) The methods/dynamic_definition.rb code example in Chapter 5 didn't convey define_method's power or a reason to use it over the def built-in.--Paolo Perrotta

#47041: Rewrite the Methods chapter to talk about the trade-offs of Ghost Methods vs. Dynamic Methods. Show the two main Ghost Method spells (the "difficult" case of Dynamic Proxy and a new spell, maybe named Convenience Ghost, for cases when you use method_missing() for convenience reasons). End by picking Dynamic Methods in the main example over Ghost Methods.--Paolo Perrotta

#46467: "Note that define_method() is executed inside the definition of Computer..."

As the author noted, that should be:

"Note that define_component() is executed inside the definition of Computer.."

...which refers to the last three lines of the class--the lines where define_component() is called--not the definition of define_component().

However, why is that class method approach even taken? Why not simplify the example and call define_component() from inside initialize()? Inside initialize() self is the object, and if you called define_component() inside initialize(), then define_component() could be defined as a regular instance method.

Regressing for a moment, what the text fails to mention is that Module#define_method() is a *private* method. As the text explained earlier, private methods cannot be called explicitly by an object--private methods have to be called without a "receiver". And when a private method is called, the receiver becomes whatever self is at that moment.

Now, because the goal is to define regular instance methods inside the Computer class using define_method(), when we call define_method(), at that instant self must be Computer. If self isn't Computer, then define_method() won't create instance methods in the Computer class.

When is self equal to Computer? Inside a class method! When a class is used to call a method, inside the method self is the class. That is exactly analogous to when you call an instance method with an instance/object of the class--inside the method, self is the instance/object.

As a result, if you create a wrapper method around define_method() and you make the wrapper method a class method, then the receiver for define_method() will be Computer, and Computer will be populated with regular instance methods.--7stud

#50164: When the ^__ methods get added to the regex in more_blank.rb, the regex gets a little looser in other respects. The resultant regex does match respond_to?, but only because it matches the respond_t part (since the ? isn't escaped). Also, the anchors got stripped from the final two method names.

I would probably use something like /^(?:__.*|method_missing|respond_to\?)$/. Others might use /^__|^method_missing$|^respond_to\?$/ or /^__|^(?:method_missing|respond_to\?)$/. My preference is for the first alternative since I find it the most explicit. The .* makes it clear that I mean __ followed by anything, I have one ^ and one $ at their respective ends of the regex and they are always used so I don't have to waste cycles figuring out if I'm missing them somewhere or if they were omitted from one of the alternatives on purpose.

--Toby Ovod-Everett
toby@ovod-everett.org--Toby Ovod-Everett

#51433: In the method_missing definition, args[0] is being passed in the @data_source.send call. However, the various methods being called actually need the @id (as seen in previous pages/revs). Is there something I'm missing here? This implementation seems to imply that one must call my_computer.cpu 42 in order to get the cpu info for computer 42. But, the example farther down the page does not show an id being passed in the my_computer.cpu call.

#50131: the switch from "info = @data_source.send("get_#{name}_info", @id)" to "info = @data_source.send("get_#{name}_info", args[0])" in chapter Methods is a bit confusing. Kado suggested changing everything to the @id form, which I did - but as a result, the *args argument of method_missing() is never really used. I should find a way to make this less confusing in the next edition.
--Paolo Perrotta

#48358: At the beginning of section 3.7, the boss writes a `test_events.rb` file that includes two events, both of which get triggered. The example would be more complete if it also had an event that did not get triggered, e.g.

event "Everything is OK!" do
@sky_height > @mountain_height
end

--Katrina Owen

#43087: The 'lambda.call' solution does not seem to clear the setups and events variables for each new events file, whereas the previous solution on page 97 did.

#48359: "[setups and events are] evaluated in the context of an `Object` that acts as a _Clean Room_".

It would be very helpful if the example on page 96 failed if you don't use a Clean Room. In the current version, it works if you use `block.call` for both setups and events.

Blocks are somewhat mind-bending, so it would be extremely useful to have an extensive failing test suite to force the reader to understand the subtleties and implications.--Katrina Owen

#41771: The test cases for the redflag example are too simple to preclude a number of more simplistic solutions to the problem. In particular there's nothing that requires the "clean room" approach, e.g.., nothing in those test cases fails if you just put everything at the top level scope:

@events = Hash.new
@setups = []

def event(name, &block)
@events[name] = block
# puts "ALERT: #{name}" if yield
end

def setup(&block)
@setups << block
end

Dir.glob('*events.rb').each do |file|
load file
@events.each do |name, event|
@setups.each { |setup| setup.call }
if event.call
puts "ALERT: #{name}"
end
end
end

I realize that you've just discussed things like clean room and instance_eval, so the reader might be inclined to use them, but it would be nice if the tests pushed the reader in that direction.--Nic McPhee

#42023: I like your example answer ( blocks/monitor_framework/redflag.rb ) but I see some issues ... I'm sorry if I'm wrong in my assumptions.

- The event names could collide, silently. I know this is just a sample ( that you quickly replace but it was the first thing that popped into my head and distracted me from the following code for a while ).
- All of the setup blocks are iterated for each event in cleanroom objects, it really doesn't just remove the "global" nature of the @variables in the setup blocks, it removes their shared nature between events.--Jeff Wood

#45413: In the GUT, rule 6 needs a little hint that the class of a class object will be class Class at the top of the eigenclass chain. Seeing figure 4.6 made rule 6 clear. The placement of the object Class isn't mentioned until figure 4.6, which is a page too late (in v1.0). --Fred Nixon

#44211: A third problem with the Around Alias is that it pollutes the name space and might clash with an existing or future name.

Why not present the alternative formulation which captures a reference to the old method in a variable and uses that in the wrapped call?--Rich Morin

#47913: From pwim on Twitter: "4.5 Quiz: Module Trouble seems to fall outside of The Great Unified Theory. Is including modules not part of the object model?". Good point, the "theory" list needs to talk about module inclusion.--Paolo Perrotta

#43256: The author suggests that you can't support methods that accept blocks, such as Array#find, with dynamic dispatch, and thus you'll need to resort to eval(). I don't agree; I've only been reading up on Ruby for a month so maybe I'm missing something? Surely the ability to convert a block into a Proc by having a third argument to a method with a preceding '&', and then from this Proc to the block required by find() etc with another, allows this?

def explore_array(method,*args,&block)
['a','b','c'].send(method,*args,&block)
end

a = explore_array(:find,[]) do |x|
x == 'b'
end
p (a == 'b' ? "Book wrong - you can" : "Book right - you can't") + " support blocks without eval" # => Book wrong - you can support blocks without eval

Fantastic book either way, it's almost brought me to an understanding of eigenclases, I've got that good brain ache feeling :)

Cheers,

Tim Ruffles--Tim Ruffles

#49936: In the proc{ ... }.call, the $SAFE works differently from normal global variable. I wrote a simple test like this:

$ABC = 'abc'
puts $ABC # abc
proc {
$ABC = 'cde'
puts $ABC # cde
}.call
puts $ABC # cde

Why is $SAFE different? I hope you can talk about it in the book.

I would appreciate if you can tell me why.

My email is: yzhang.wa@gmail.com

Thanks,
Yi Zhang--Yi Zhang

#42010: The text says, "It [erb] ... also creates a Clean Room (109) to execute the code in a separate scope." P. 109 shows how to create a clean room by calling instance_eval on an object; p. 122 uses that technique again. I don't see that happening in the ERB snippet at the top of p. 175. Is this code using a different method of making a clean room? Is the instance of ERB the clean room?
--Wayne Conrad

#42849: Nill Guards do not work well with booleans.
a = false # a gets initialized
....
a ||= true # initialization gets overwritten
Effectively, it guards both against nil and false.
A pitfall that cost me quit some time, once....
Should be explained more clearly, I think.--Martijn Bak