From: Sean O'Dell <sean@...>
Date: 2004-06-17T12:46:50+09:00
Subject: Re: [OT] RE: require vs require_gem

On Wednesday 16 June 2004 20:40, Mehr, Assaph (Assaph) wrote:
> > If you are writing a program for home or work use, where you control
>
> the
>
> > runtime environment, then this is a reasonable approach:
> >  * in the "base file" of your project, require 'rubygems'
> >  * in other project files, require the "base file"
> >  * now 'require_gem' is available wherever you like
> >
> > For instance, my work project is called 'dmv1'.  Nevermind what that
> > means.  So I have 'lib/dmv1.rb' which is the "base file", which
>
> defines
>
> > some modules, constants, etc., that are used across the board.
> > 'lib/dmv1/**/*.rb' all "require 'dmv1'" and build on those modules.
>
> So
>
> > without any real effort -- just some thought in project structure --
> > require_gem is available everywhere.
>
> What you describe doesn't quite follow the Ruby 'require' process.
> 'require' isn't the same as #include of java's import: you do not need
> to require a library from every file that uses it. Once you have
> require'd a file everything in it has already been brought in to the
> interpreter.
>
> For an app/lib type of work you describe, where users will always call
> through the "base file", you can just put all your requires there (or in
> one file called from the base). This has the advantage that you can deal
> with all external libraries and their versions in one place.

I find it's better to spread out the requires (not too liberally), so you only 
load libraries when they're really needed.  Sometimes a program won't use 
some of the "require" files, so it's possible to avoid unnecessary loading of 
libraries it won't use.

	Sean O'Dell