class destruction (evil genius metaprogramming)

G

Giles Bowkett

I want to write a module which, when included in another module,
destroys every method of a class in that module. I realize this isn't
really a very useful thing to do, but I want to do it to see if it can
be done. I want to actually include the module and have it replace all
existing methods of this class with just one method.

In Python you can change an object's class in the middle of your
program by reassigning its magical __class__ variable. That would be a
very simple way to implement this idea. Doesn't seem possible here,
though.

Here's an attempt which failed:
NoMethodError: undefined method `show' for #<Muppet:0x123129c>
from (irb):36
from :0

So far so good, but I want to get rid of *every* method. Doing what I
just did programmatically, iterating over all available methods,
that's the thing which still eludes me.

None of these attempts work:
NameError: undefined local variable or method `m' for #<Class:Muppet>
from (irb):43
from (irb):43:in `each'
from (irb):43
from :0NameError: undefined local variable or method `m' for Muppet:Class
from (irb):44
from (irb):44:in `each'
from (irb):44
from :0NoMethodError: undefined method `remove_method' for #<Object:0x349f4>
from (irb):45
from (irb):45:in `each'
from (irb):45
from :0

I have to admit, it's not necessarily a bad thing if this task proves
impossible, but I feel like it *should* be possible.
 
R

Rick DeNatale

I want to write a module which, when included in another module,
destroys every method of a class in that module. I realize this isn't
really a very useful thing to do, but I want to do it to see if it can
be done. I want to actually include the module and have it replace all
existing methods of this class with just one method.

In Python you can change an object's class in the middle of your
program by reassigning its magical __class__ variable. That would be a
very simple way to implement this idea. Doesn't seem possible here,
though.

Here's an attempt which failed:

NoMethodError: undefined method `show' for #<Muppet:0x123129c>
from (irb):36
from :0

So far so good, but I want to get rid of *every* method. Doing what I
just did programmatically, iterating over all available methods,
that's the thing which still eludes me.

None of these attempts work:

NameError: undefined local variable or method `m' for #<Class:Muppet>
from (irb):43
from (irb):43:in `each'
from (irb):43
from :0
NameError: undefined local variable or method `m' for Muppet:Class
from (irb):44
from (irb):44:in `each'
from (irb):44
from :0
NoMethodError: undefined method `remove_method' for #<Object:0x349f4>
from (irb):45
from (irb):45:in `each'
from (irb):45
from :0

I have to admit, it's not necessarily a bad thing if this task proves
impossible, but I feel like it *should* be possible.
Click to expand...

kermit.class.instance_methods(false).each{|m|
Muppet.instance_eval("remove_method #{m.inspect}")}

Note 1. kermit.methods will return all methods inherited or not.
Note 2. remove method is a class method, so it's evaluated in the
context of the class object, hence Muppet.instance_eval
Note 3: you could alternatively pass symbols for the method names

kermit.class.instance_methods(false).each{|m|
Muppet.instance_eval("remove_method :#{m}")}



--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/
 
G

Giles Bowkett

kermit.class.instance_methods(false).each{|m|
Muppet.instance_eval("remove_method #{m.inspect}")}

Note 1. kermit.methods will return all methods inherited or not.
Note 2. remove method is a class method, so it's evaluated in the
context of the class object, hence Muppet.instance_eval
Note 3: you could alternatively pass symbols for the method names

kermit.class.instance_methods(false).each{|m|
Muppet.instance_eval("remove_method :#{m}")}
Click to expand...

Muahahaha! That was awesome! Soon the world will quake in fear when I
put this information to use!

But why doesn't this work?
kermit.methods(false).each do |m| ?> Object.instance_eval("remove_method :#{m}")
end => []
kermit.methods
Click to expand...
Click to expand...
=> 53

I tried it with Kernel also and no dice.

Tried it with something else, though, and got a great error message:

(eval):1: warning: removing `initialize' may cause serious problem

Muahahaha!
 
D

dblack

Hi --

kermit.class.instance_methods(false).each{|m|
Muppet.instance_eval("remove_method #{m.inspect}")}

Note 1. kermit.methods will return all methods inherited or not.
Note 2. remove method is a class method, so it's evaluated in the
context of the class object, hence Muppet.instance_eval
Note 3: you could alternatively pass symbols for the method names

kermit.class.instance_methods(false).each{|m|
Muppet.instance_eval("remove_method :#{m}")}
Click to expand...

You can also just use the block form of instance_eval:

Muppet.instance_eval { remove_method(m) }


David

--
* Books:
RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 
R

Robert Dober

Hi --



You can also just use the block form of instance_eval:

Muppet.instance_eval { remove_method(m) }
Click to expand...

or Muppet.send :remove_method, :m

Cheers
Robert
 
D

dblack

Hi --

kermit.class.instance_methods(false).each{|m|
Muppet.instance_eval("remove_method #{m.inspect}")}

Note 1. kermit.methods will return all methods inherited or not.
Note 2. remove method is a class method, so it's evaluated in the
context of the class object, hence Muppet.instance_eval
Note 3: you could alternatively pass symbols for the method names

kermit.class.instance_methods(false).each{|m|
Muppet.instance_eval("remove_method :#{m}")}
Click to expand...

Muahahaha! That was awesome! Soon the world will quake in fear when I
put this information to use!

But why doesn't this work?
kermit.methods(false).each do |m| ?> Object.instance_eval("remove_method :#{m}")
end => []
kermit.methods
Click to expand...
Click to expand...
=> 53
Click to expand...

kermit.methods(false) will give you kermit's singleton methods:

irb(main):019:0> s = ""
=> ""
irb(main):020:0> def s.x; end
=> nil
irb(main):021:0> s.methods(false)
=> ["x"]

Also, you can't remove these methods from Object because they're not
defined there. You'd have to do:

class << s
remove_method:)x)
end


David

--
* Books:
RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 
R

Robert Dober

Hi --



If you have a method called "m" :)
Click to expand...
Ah I see :(, Probably 50% of my errors come from spurious ":" ARRRRG

Muppet.send :remove_method, m ### TESTED ;)

Sorry.
Robert
 
G

Giles Bowkett

Why should this inspire fear?
Code injection attack to own a RoR site possibly? That would be my guess.
Click to expand...

Sort of. I'm trying to use it to build a Rails plugin called
acts_as_fox, which overrides every method on a model to return "chunky
bacon!" (It's not really that terrifying, I just kind of had a Dr.
Frankenstein moment, drunk on power type thing.)

Unfortunately, applying Rick's code directly to an ActiveRecord model
doesn't quite accomplish this, because it's missing the superclass
methods, but applying it to ActiveRecord::Base doesn't work either. I
did get it to work by doing it twice, both on the actual model and on
ActiveRecord::Base itself, but that's very unsatisfying, because I
solved the problem by cutting and pasting. (I think I understand why
it worked; ActiveRecord::Base attaches a lot of methods to its
subclasses, instead of having them inherited directly.) It also fails
to really accomplish what I want to do, because it means that making
one model acts_as_fox destroys all the other models. (I also need to
attach a method_missing to return "chunky bacon!" but that part's
obviously trivial.)

Really the quickest way to accomplish this would be to simply pop the
model out of its inheritance hierarchy - redefine the model not to
have any superclass except Object - but I don't know if that's
possible. Trying it in the most obvious way (class Foo < Object; end,
where Foo was already defined Foo < ActiveRecord::Base) results in a
TypeError with the message "superclass mismatch."

But there must be a clean way to open up the class, grab all its
methods, including those derived from superclasses, and simply
reassign them. Something like

Foo.instance_methods(true).each{|m| Foo.instance_eval("alias
:chunky_bacon " + m)}
 
D

dblack

Hi --

Sort of. I'm trying to use it to build a Rails plugin called
acts_as_fox, which overrides every method on a model to return "chunky
bacon!" (It's not really that terrifying, I just kind of had a Dr.
Frankenstein moment, drunk on power type thing.)

Unfortunately, applying Rick's code directly to an ActiveRecord model
doesn't quite accomplish this, because it's missing the superclass
methods, but applying it to ActiveRecord::Base doesn't work either. I
did get it to work by doing it twice, both on the actual model and on
ActiveRecord::Base itself, but that's very unsatisfying, because I
solved the problem by cutting and pasting. (I think I understand why
it worked; ActiveRecord::Base attaches a lot of methods to its
subclasses, instead of having them inherited directly.) It also fails
to really accomplish what I want to do, because it means that making
one model acts_as_fox destroys all the other models. (I also need to
attach a method_missing to return "chunky bacon!" but that part's
obviously trivial.)

Really the quickest way to accomplish this would be to simply pop the
model out of its inheritance hierarchy - redefine the model not to
have any superclass except Object - but I don't know if that's
possible. Trying it in the most obvious way (class Foo < Object; end,
where Foo was already defined Foo < ActiveRecord::Base) results in a
TypeError with the message "superclass mismatch."
Click to expand...

I do sometimes wonder what would happen if the ancestry array were
writeable. It could be interesting. I haven't thought through the
possible pitfalls.
But there must be a clean way to open up the class, grab all its
methods, including those derived from superclasses, and simply
reassign them. Something like

Foo.instance_methods(true).each{|m| Foo.instance_eval("alias
:chunky_bacon " + m)}
Click to expand...

Here's a little demo that does pretty much that (sparing the _ methods
like __send__):

class Object
def mask
puts "I'm masking a method"
end
end

class C
def x
puts "x"
end

def y
puts "y"
end
end

class D < C
def z
puts "z"
end
end

class D
instance_methods.reject {|m| /^_/.match(m) }.each do |m|
alias_method m, :mask
end
end

C.new.x # x
D.new.x # I'm masking a method
D.new.z # I'm masking a method


David

--
* Books:
RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 
D

Devin Mullins

I do sometimes wonder what would happen if the ancestry array were
writeable. It could be interesting. I haven't thought through the
possible pitfalls.
Click to expand...

You mean, like Object#become? :)

Seriously, how would that play with the core classes, which don't keep
their state in instance variables?

Devin
 
R

Rick DeNatale

I do sometimes wonder what would happen if the ancestry array were
writeable. It could be interesting. I haven't thought through the
possible pitfalls.
Click to expand...

Actually the ancestry array only exists as the return value of the
ancestry method, internally it's a chain of class objects, and module
wrapper's. Some things, like including a module will alter that
chain, although there are restrictions which lead to things like the
double module inclusion problem.

Perhaps evil.rb lets you monkey with the chain, it would seem to be
within its mission.
 
D

dblack

Hi --

You mean, like Object#become? :)
Click to expand...

Not exactly. As I understand it, #become involves references changing
from one object to another. I'm thinking of something more like:

module M
end

a = Object.new
class << a
ancestors.unshift(M) # essentially same as a.extend(M)
end
Seriously, how would that play with the core classes, which don't keep their
state in instance variables?
Click to expand...

I'm not sure how that would matter specifically. What problem are you
envisioning? (Not that the whole thing wouldn't be a train-wreck
anyway :)


David

--
* Books:
RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 
D

dblack

Hi --

Actually the ancestry array only exists as the return value of the
ancestry method, internally it's a chain of class objects, and module
wrapper's.
Click to expand...

By making it writeable I meant making it an interface to the chain
itself. Obviously you can do:

String.ancestors << "blah"

but that wasn't the point :)


David

--
* Books:
RAILS ROUTING (new! http://safari.awprofessional.com/9780321509246)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 
G

Gregory Brown

Hi --



Not exactly. As I understand it, #become involves references changing
from one object to another. I'm thinking of something more like:

module M
end

a = Object.new
class << a
ancestors.unshift(M) # essentially same as a.extend(M)
end
Click to expand...

Would you want to be able to switch ordering too? I wonder what kind
of interesting evil could come of that...
 
G

Giles Bowkett

I do sometimes wonder what would happen if the ancestry array were
...

Would you want to be able to switch ordering too? I wonder what kind
of interesting evil could come of that...
Click to expand...

You can play with this in Python. If you modify the __class__ magic
var you can change an object's class in real-time. When I first
discovered this, I posted on a Python list that it seemed like a
sportscar without a seatbelt, and got some very outraged responses
from Python programmers who felt passionately that it was one of the
language's best features. The most memorable response turned my words
around ("sportscar without a speed limit").

On the flipside, I also heard a story from a guy who found this kind
of thing heavily abused in some legacy bioinformatics code in Python,
and he was not happy about it. Objects would wander off into
particular methods and come back home completely transformed. It
sounded very confusing.
 
G

Giles Bowkett

Here's a little demo that does pretty much that

gracias!
(sparing the _ methods
like __send__):
Click to expand...

no mercy! no survivors!
class Object
def mask
puts "I'm masking a method"
end
end

class C
def x
puts "x"
end

def y
puts "y"
end
end

class D < C
def z
puts "z"
end
end

class D
instance_methods.reject {|m| /^_/.match(m) }.each do |m|
alias_method m, :mask
end
end

C.new.x # x
D.new.x # I'm masking a method
D.new.z # I'm masking a method
Click to expand...

I tried something very similar and it failed, but I can't recall why.
I'll check this later in the day.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

ruby thread is buggy while using serialport 7
Integer class error 3
Metaprogramming conventions 1
ruby unicode/string explosion (0xFF in utf-8) 2
require files namespace! 3
Help needed for Ruby & Watir Configuration 1
PyMyth: Global variables are evil... WRONG! 20
How to dynamically include a module and update top level? 6

Members online

Total: 49 (members: 3, guests: 46)
Robots: 505

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top