[Rubygems-developers] OO gems? (was Re: What plns now?)

Gavin Sinclair gsinclair at soyabean.com.au
Sun May 16 18:24:29 EDT 2004


>> What about beyond that?  I'd like to bring about some unification in
>> the code base.  At the moment, gem objects don't have primacy.  The
>> code is more about processes than about data.  I'd like to see some
>> sort of class hierachy that gives you access to all sorts of gems:
>> local and remote, installed and uninstalled.
> 
> I'm all for making the API more convenient and powerful, but I don't 
> think I'm very close to being sold on doing it via Gem inheritance.  In 
> this context, I'd say that a gem is a gem.  You can store it locally or 
> remotely and you can install and uninstall it, but it's still a gem.  
> These really *are* processes, right?
> 
> I could see how this could be an argument for getting a little more 
> uniform about how we represent a "repository".  Maybe that's the noun 
> you're looking for?  Right now we call that 'cache', which I know you 
> hate. :)  Should we look at doing local and remote ones in an OO way?  
> I'm not sure.

The main point I'm trying to make with this, I suppose, is that ATM we
don't even have a Gem object.  We have a Gem::Specification, but
that's not the same; that's part of a gem.  I think a gem should know
whether it's installed, where its data lies (local path, for instance,
or remote server), and so on.

ATM, the information doesn't exist up-front, and it's the
responsibility of several different classes to determine it.  The code
is very procedural (like I said, process-oriented), and there's a lot
of code to glue that together that could be factored into a more
natural API.

You should be able to say "install this gem", not "local install this
gemspec" or "remote install this gemname".  The differences become
confusing.  You should be able to say "install this gem", or better:
"gem, install yourself".  (Even if Gem#install is a thin method that
delgates to LocalInstaller or RemoteInstaller, at least we would have an
intuitive API that different clients can build on.)

# Any examples of how it's done now may be incorrect.  They're based
# on a confused memory.  And that's the point! :)

Cheers,
Gavin





More information about the Rubygems-developers mailing list