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

#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

#41959: Hi Paola, I am learning a lot from the book! Great content! A suggestion for the "The Top Level" sidebar: I would extend this a bit to mention irb subsessions which allow you to change the value of self used by the interpreter. You might also mention that this is a convenient technique for exercising private methods:

irb(main):007:0> s = "abc"
=> "abc"
irb(main):008:0> s.private_methods
=> ["rand", ... ]
irb(main):009:0> s.rand
NoMethodError: private method `rand' called for "abc":String
from (irb):9
from :0
irb(main):010:0> irb s
irb#1(abc):001:0> rand
=> 0.181140548984387
--Greg Krimer

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

#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

#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

#43561: Similar to comment #41674, I'm confused about all this extra machinery. I don't see why module/mixin authors must go through such ridiculous contortions to make mixins. Ruby provides both include(foo) and extend(foo), and it seems silly to me that the whole point of all the included() hooks is just to turn around and call extend. The thing being extended is calling include! So why doesn't the API author just say "please call 'extend BlubberMixin' to get access to Blubber"?--Seth Arnold

#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