From: Paul Brannan <pbrannan@...>
Date: 2001-10-31T23:06:03+09:00
Subject: [ruby-talk:23948] Re: RubyGems Discussion

On Wed, 31 Oct 2001, Ryan Leavengood wrote:

> The drawbacks to this include:
>    - a format that is hard to read by the RubyGems system.  Most of the
> time gems will be libraries that will be accessible from 'require' like
> any other library.  But a Ruby format would require some strange 'eval'
> tricks to read them in (and wrapper classes like Rich Kilmer suggested)
> or a finished RubyInRuby parser which is complete overkill for this
> purpose.  Also imagine trying to find a single file in a gem on a system
> with 100s of gems.  You would have to load and eval each one until you
> found the one with that file.  This could be insanely slow.

Consider this:

A RubyGems file is, at the most basic level, a set of key/value pairs.
There is already builtin support in Ruby for a set of key/value pairs; we
call this a Hash.  Why not have each Gem create a class with an accessor
to a Hash with each of these key/value pairs?

Another possibility (and I do this with config files) is to put a set of
constants in the Ruby file.  You can even temporarily overload [], so you
end up with something that looks a LOT like an INI file:

[section]
CONSTANT1 = value1
CONSTANT2 = value2

As far as searching for Gems goes, you can easily create an index of all
the Gems; this way you don't have to execute each Gem every time you want
to perform a search.

Paul