[Rubygems-developers] Design notes for RubyGems 2

Chad Fowler chad at chadfowler.com
Mon Jun 7 21:43:31 EDT 2004

On 6/6/2004, at 1:24 PM, Gavin Sinclair wrote:

> <rubygems 2 design.rtf>

Gavin, thanks for the effort!

I don't see anything wrong with what you've got here (other than some 
rough bits, of course), but I also don't see the value in switching 
everything right now.  You mentioned "process-oriented" vs. 
"object-oriented" several times here on this list, and I don't see why 
"process-oriented" is a bad thing.  I'd like some concrete examples of 
where the code needs specific help or the current design gets in the 
way in some fundamental way.

I do believe there are plenty of places that need refactoring, but I 
don't think we have a fundamentally bad design.

Back to "process" vs. "data"...your design document takes some of the 
real-world concepts we discuss as we deal with RubyGems and makes them 
into classes that can be instantiated and manipulated.  I can see how 
this would be one good approach you could take to designing the 
RubyGems system, but I don't think the absence of these objects is a 
bad thing.  I think they are just equal alternatives for 
conceptualizing and implementing the system.  To me, a "Gem" is an 
abstract thing.  it is, as you say in the document, files and metadata. 
  To me, that's why it doesn't really make sense to have a "Gem" object.

What we probably need is to refactor and clean up some of our "process" 
code, possibly pushing things down into the API as it makes sense.

My mind isn't shut, but I'm starting out not seeing a reason to switch. 
  If we were starting from scratch, I'd be more likely to jump on these 


More information about the Rubygems-developers mailing list