Weapon = wearable(obtainable(wieldable(Obj)))
Sword = damage(:slash, Weapon)
class MissingHook < Exception
end
class Module
def required_hooks(*hooks)
hooks.each do |hook|
class_eval "def #{hook}(*args); raise MissingHook, '\\'#{self}\\' requires that \\'#{hook}\\' be implemented.'; end"
end
end
end
module Consumes
required_hooks :eat, :drink
end
class Character
include Consumes
def eat(food)
puts "eating #{food}"
end
end
character = Character.new
character.eat 'meat' # => "eating meat"
character.drink 'water' # Exception raised: 'Consumes' requires that 'drink' be implemented.
class Inventory
def initialize(s)
add_item(s)
end
def add_item(i)
puts "you have added a #{i} to your inventory."
end
end
module Carries
def self.included(base)
base.class_eval %Q{
@inventory = Inventory.new("Blade of Gondor")
attr_accessor :inventory
}
end
end
class Player; include Carries; end
p = Player.new
puts p.inventory
#OUTPUT:
# => you have added a Blade of Gondor to your inventory.
# => nil
similar behavior could really benefit from sharing modules. I guess the Ruby Way would be to mix-in the modules and
only override what is necessary. What scares me about this idea, is say your lib has 100 base objects, and you are
mixing-in multiple modules per object. It seems that without great care, things could get out of hand.
By the way, I'm talking more of an LPC approach which may be the problem. I would be using a file based system that
takes advantage of scripting at run-time. An example might look like: