ptkwt / shell1.aracnet.com (Phil Tomson) writes:

> 
> I've thought of this, but I think most of the methods from Runnable would 
> be overridden anyway so the only thing it seems to buy me is that I could 
> have a 'run' method in runnable that, if not overidden in the class 
> Runnable is mixed-into, raises an exception.

Part of my thinking is that the Runnable mixin could be totally
empty. The idea would be that it is an acknowledgment by users of the
framework that they've read the documentation it contains. Something
like:

 Framework provider supplies Runnable, containing just a comment

    module Runnable
     # Objects distributed by the framework should implement a
     # 'run' method that ...
     #
     # In addition they can implement 'wombat' and 'koala' that ...
     #
     # To help future generations understand you code, you could
     # place 'include Runnable' in each of your runnable class
     # definitions. This gives you no added functionality, but
     # does provide a pointer to this documentation for
     # readers of the future :)
    end

 Framework user reads the documentation and thinks, "hmmm, Phil
 already wrote part of the documentation for my classes..." and
 does

    class Widget
      include Runnable

       ....
    end

    class Blodger
      include Runnable

      ...
    end

So the include here is nothing more than a documentation proxy.


> What I'll probably end up doing is just doing a test in the class which 
> distributes these 'runnable' objects to ensure that the object being 
> passed along contains a 'run' method: 

I think that's just the way to do it.


Dave