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
···
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 second that, and actually put some 'require' statements in methods right
before I use them. That way if a method is called, the library is loaded,
otherwise not:
def load_from_yaml(filename)
require 'yaml'
YAML.load(File.read(filename))
end
So if this method is called, yaml is loaded (if necessary), otherwise its
not.
-rich
···
On 6/16/04 11:46 PM, "Sean O'Dell" <sean@celsoft.com> wrote:
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.
Note that this could bite you:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/95409
···
On Thu, Jun 17, 2004 at 12:53:08PM +0900, Richard Kilmer wrote:
I second that, and actually put some 'require' statements in methods right
before I use them. That way if a method is called, the library is loaded,
otherwise not:
def load_from_yaml(filename)
require 'yaml'
YAML.load(File.read(filename))
end
So if this method is called, yaml is loaded (if necessary), otherwise its
not.
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
Checking host system type...
i586-unknown-linux
configure: error: sorry, this is the gnu os, not linux
-- Topic on #Linux
Another possibility would be to
autoload :YAML, 'yaml'
at the beginning of your file. The advantage is that you can mass all your dependencies at one place and only have to do that once even if more than one method requires the file.
Florian Frank
···
On 17.06.2004, at 05:53, Richard Kilmer wrote:
I second that, and actually put some 'require' statements in methods right
before I use them. That way if a method is called, the library is loaded,
otherwise not:
def load_from_yaml(filename)
require 'yaml'
YAML.load(File.read(filename))
end
So if this method is called, yaml is loaded (if necessary), otherwise its
not.