From: Trans <transfire@...>
Date: 2007-01-05T12:49:03+09:00
Subject: Re: File-based Code Encapsulation


ara.t.howard@noaa.gov wrote:
> On Thu, 4 Jan 2007, Trans wrote:
>
> > Hi--
> >
> > I'm having a little debate with myself. On my current project I have a
> > bunch of little reusable task scripts that a command line tool runs.
> > The scripts are written as the top-level (although I actually simulate
> > the top-level when running them). So for example a script would just be
> > something like:
> >
> >  # example.rb
> >
> >  def example
> >    puts "This is an example!"
> >  end
> >
> > Then on the command line I would do:
> >
> >  % mytool example
> >  This is an example!
> >
> > That's all well and good, but many of the scripts have generally useful
> > routines and I would like them to be accessible by other programs too,
> > not just my command line tool. So I thoght maybe it would be better if
> > a module were required to wrap the defs.
> >
> >  # another.rb
> >
> >  module MyToolAnother
> >
> >    def another
> >      puts "This is another!"
> >    end
> >
> >  end
> >
> > That works, of course, but it adds an additonal layer of essentially
> > redundant code, which IMHO is ugly.
> >
> > Then I got to thinking. Why don't we write resuable lib in this fashion
> > anyway and just create our own containers on the fly when loading them?
> >
> >  MyToolExample = load_as_module "example.rb"
> >
> > What intersting about that is then we could determine in what capacity
> > it is to be used. For example:
> >
> >  # adds module_function
> >  MyToolExample = load_as_function_module "example.rb"
> >
> >  # adds self extend
> >  MyToolExample = load_as_self_extended_module "example.rb"
> >
> > Or even
> >
> >  MyToolExample = load_as_class "example.rb"
> >
> > We could even have include and extend take a lib path.
> >
> >  include "example.rb"
> >
> > Of course this effectively puts encapsulation, at least at the top
> > level, on a per-file basis. But in many respects that seems kind of
> > nice. It increases flexability and reduces configuration complexity.
> >
> > So what do your think? Is this technique worth promoting? Or am I being
> > silly and should just wrap all my scripts in modules?
> >
> > T.
>
> wrap up the functionality into a lib, require that from your scripts, and make
> accessing instance methods from the command-line easy.

in this particluar case it's not suitable to separate the functionality
into separate lib b/c it's important that these scripts be
self-contained.

>  i've used this pattern
> many times.  here is an example from our NRT (near-real-time) system which
> allows me to call any module function from the command line:
>
> [snip examples]
>
> the result is that any library/module routine is instantly availible from the
> command line - makes testing a breeze!
>
> obviously not all routines are easy to use this way but, by sticking to simple
> interfaces/function call signatures many of them can be.
>
> it's a useful pattern.
>
> food for thought.

very cool. yea, i wondn't mind adding a tool like that to my current
project. i wonder how extensive a tool like that could be. would it be
possible to run arbitrary methods --even if they were in classes or
non-function modules?

T.