This is really great, but I would b verbose:

    dependsOn     Gem("RyansCoolGem") >= Version(0, 0, 2)
    conflictsWith Gem("RyansCoolGem") >= Version(0, 0, 2)
    recommends    Gem("RyansCoolGem") >= Version(0, 0, 2)

Its just clearer that way.  (its really a nitty point...)

Question:  Should the gem file be made to create an object,
or be "eval'ed" into an object?

If it created an object within a global repository (but did
not necessarily load the file data) that would seem best to 
me.  Then the system would simply load each file...with each
one registering its gem(s) into the active repository.

Then, like Robert said, those objects could conform to a
contract to load their file data from (within) their physical
file/archive on demand.

-Rich

> -----Original Message-----
> From: dave / thomases.com [mailto:dave / thomases.com]On Behalf Of Dave
> Thomas
> Sent: Tuesday, October 30, 2001 9:04 AM
> To: ruby-talk ML
> Subject: [ruby-talk:23843] Re: RubyGems Status (was: Re:
> Someinspirations from REBOL)
> 
> 
> Robert Feldt <feldt / ce.chalmers.se> writes:
> 
> > On Tue, 30 Oct 2001, Dave Thomas wrote:
> > 
> > >   dependsOn Gem("RyansCoolGem") >= V(0, 0, 2)
> > > 
> > Yes, and maybe V() can also take a string as in V("0.0.2") and 
> produce the
> > version object. I'm not sure I understand your Gem constructor 
> though. How
> > can it represent different dependency types? Wouldn't it be better with
> > dependency hierarchy
> > 
> > class Dependency; ...; end
> > class Requires < Dependency; ...; end
> > class Recommends < Dependency; ...; end
> 
> it struck me that it was more natural to put that relationship
> separate from the Gem name:
> 
>    dependsOn     Gem("RyansCoolGem") >= V(0, 0, 2)
> 
>    conflictsWith Gem("RyansCoolGem") >= V(0, 0, 2)
> 
>    recommends    Gem("RyansCoolGem") >= V(0, 0, 2)
> 
> 
> Dave