Forum: Ruby dynaload-0.2.0

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ara.T.Howard (Guest)
on 2005-12-13 08:48
(Received via mailing list)
URIS
   http://raa.ruby-lang.org/project/dynaload/
   http://www.codeforpeople.com/lib/ruby/dynaload/

NAME
   dynaload.rb

DESCRIPTION
   a simple toolset to make dynamic loading of classes and modules
easier

   imagine you have many files containing the following kinds of class
   definitions

     class ClassName
       def method
       end
     end

   you'd like to be able to dynamically load the file defining a class,
   instantiate the class(es) defined in it, and and run ClassName#method
on an
   instance WITHOUT knowing beforhand which class will be loaded.
dyanload
   solves this problem.  classes wishing to be dyanloaded do the
following

     ----------------
     file: 1.rb
     ----------------
       require 'dynaload'

       class ClassOne
         def answer
           42
         end
       end

       Dynaload::export ClassOne, 'answer' => true

     ----------------
     file: 2.rb
     ----------------
       require 'dynaload'

       class ClassTwo
         def answer
           42
         end
       end

       Dynaload::export ClassTwo, 'answer' => true

   the options hash ('answer' => true) may contain anything deemed
useful and is
   entirely dedicated for user data

   now both files can be dynaloaded, the classes instantiated, and
methods called
   with

     require 'dynaload'

     %w( 1.rb 2.rb ).each do |file|
       loaded = Dynaload::dynaload file

       klasses = loaded.select{|klass, attributes| attributes['answer']
== true}

       klasses.each do |klass, attributes|
         object = klass::new
         p object.answer
       end
     end

   any class or module defined in a file can be exported and is then
available
   via the Dynaload interface.  for instance:

     class C
       module M
         class B
           Dynaload::export B
         end
       end
     end
     Dynaload::export C

   is valid and exports only the classes C and B - not C::M.

   the concept works best with modules as the exported quantities and
loading
   within an anonymous wrapper module (the default) to protect the
namespace.
   eg.

     ----------------
     file: 1.rb
     ----------------

       require 'dynaload'

       module FooJob
         def run
           ...
         end
       end

       Dynaload::export FooJob

     ----------------
     file: 2.rb
     ----------------

       require 'dynaload'

       module BarJob
         def run
           ...
         end
       end

       Dynaload::export BarJob

     loading is done (by default) in an anonymous module so neither
FooJob or
     BarJob is introduced into the caller's namespace:

       require 'dynaload'

       loaded = Dynaload::dynaload('1.rb') | Dynaload::dynaload('2.rb')

       modules = loaded.modules

       # here neither FooJob or BarJob are polluting namespace



SAMPLES/DOCS
   see samples/*


CAVEATS
   this software is experimental and quite simple


enjoy.


-a
This topic is locked and can not be replied to.