4

I would like to put some code in module that throws an error if certain method is not defined. This module relies on the external definition of this method, since this method's implementation is different for all classes. This code would help developers know early that they forgot to implement the method rather than when they tried to use features of the module.

module MyModule
  def self.included(klass)
    raise "MyModule: please `def my_method` on #{klass}" unless klass.respond_to?(:my_method)
  end
end 

I can easily raise an error in a module's included definition if a method is not defined, however since most modules are included at the top of a file, it's likely that my required method is defined in the class, but not before my module is included.

class MyClass
  include MyModule
  def self.my_method
    # ...
  end
end

This would still raise an error :(

Is it possible to raise an error only if the method truly is not defined in the class definition? Almost need a class.onload callback of sorts. If not, any other ideas for how to mitigate the possibilities that a programmer might include our module without defining this needed method?

Schneems
  • 14,918
  • 9
  • 57
  • 84

3 Answers3

6

Sounds like you want to make use of method_missing and define_method.

If you do use method_missing don't forget to:

  • call super for unhandled cases.
  • also implement a respond_to? method

look at this question, plus this and that.

Update:

It sounds the goal is to do static method checking like Java or c++ does. This is not really meaningful in ruby :-(

Since in ruby:

  • Each instance of an object has its own eigenclass. A given object may have the necessary methods mixed in at runtime. So just because Foo does not have a method at class load time is meaningless.
  • Frameworks like RoR hooks method_missing and dynamically create methods needed for the database query methods, so the method may exist (or not) when it is needed.

With regards to "class on load": A class definition is really executed. Try this:

class Foo 
  p "Hi"
end

You will see "Hi" the first and only the first time Foo is used. This is how things like devise hook into do their magic.

class User < ActiveRecord::Base
  # **CALL 'devise' method**
  devise :database_authenticatable, :registerable, :recoverable, :rememberable, :trackable, :validatable

  # **CALL attr_accessible method**
  attr_accessible :email, :password, :password_confirmation
end

So maybe by private convention have developers add a check_class method call to the bottom of the classes in question?

I understand the intent but it seems like fighting the way ruby is designed to work.

As a mostly Java person I appreciate the frustration. Let me guess: repeated cases of code getting pushed to production that had missing methods? :-P

Update2:

wrt onload In ruby barring use of frozen a class get new methods defined all the time. ( Or an instance can get new methods defined just for that instance. ) so checking for a method's nonexistence is only a snapshot check and not as definitive a check as a static language brings to the table. This is ruby's very own Halting problem

Community
  • 1
  • 1
Pat
  • 5,761
  • 5
  • 34
  • 50
  • 1
    I'm familiar with eigenclasses, and yes i'm trying to do something like static method checking. One of my co-workers pointed out we could move this expectation into the tests for models implementing MyModule. We could have a macro acts_as_my_module that we can mixin with all models tests/specs. Still won't complain as loudly, and requires extra programmer dedication, but is the most ruby-esque – Schneems Jul 29 '11 at 18:28
  • If you're using rspec you can do something like this http://relishapp.com/rspec/rspec-core/v/2-6/dir/example-groups/shared-examples – Schneems Jul 29 '11 at 18:29
  • all things considered, you probably do want a tool that runs as part of your deployment and stops the deployment if there is a problem like this. It sounds like you know that already but were hoping for an alternative :-) – Pat Jul 29 '11 at 18:48
  • Do not use `super` for unhandled cases. Using `super` in ruby when overriding `method_missing` will attempt to head to the next class or mixin etc in the ancestor chain and something might be found there for your method name. Instead, do `raise NoMethodError`. This is a much safer solution (coming from an enterprise rails developer who just fought the edge cases on using super). – cdownard Apr 04 '15 at 04:45
5

How about declaring a method with that name, which just raises an error, to make sure the user redefines the method?

module MyModule
  def my_method
    raise "Please implement me"
  end
end


class MyClass 
  include MyModule
  def my_method
    # do something
  end
end
Dogbert
  • 212,659
  • 41
  • 396
  • 397
  • I considered this, though you still don't feel the pain until you try to call the method. – Schneems Jul 29 '11 at 18:24
  • If you just leave out the definition altogether, it will pretty much have the same effect. In fact, it will be even *better*, since instead of raising a generic non-descript `RuntimeError` exception, it will raise a `NoMethodError` exception, which tells you pretty much all you need to know: a method that was expected to be there, wasn't. That's the idiomatic Ruby way and that's for example the way `Enumerable` and `Comparable` do it. – Jörg W Mittag Jul 29 '11 at 20:06
  • I used this way to make "abstract classes". The custom error message allows you to put justifications/reasons for why the method needs to be overridden in the comments above the raise. – KANJICODER May 09 '18 at 02:52
  • I love this beauty! – Rahul Dess Dec 16 '21 at 08:44
2

Assuming your program requires all files when started and does not use any autoload and the like, you could use something like the following right after everything is required, but before the program actually starts:

classes_to_check = Object.constants.find_all do |const|
  klass = Object.const_get(c)
  klass.ancestors.include?(MyModule) if klass.kind_of?(Module)
end

classes_to_check.each do |klass|
  raise "MyModule: please `def my_method` on #{klass}" \
    unless klass.respond_to?(:my_method)
end

However, I personally always use Dogbert's solution.

Confusion
  • 16,256
  • 8
  • 46
  • 71