[Rubygems-developers] Design notes for RubyGems 2

Curt Hibbs curt at curthibbs.us
Tue Jun 8 08:35:42 EDT 2004

Chad wrote:
> 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.

Why not establish the a well-designed, object-based interface like Gavin's
(perhaps initially as a wrapper) and then refactor into that?

> 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.

Huh? To me that is precisely why its makes sense to have a Gem as an 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.

I would go for the object-based wrapper approach I mentioned above, and push
things "up" into the api.

> 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
> ideas.

Theoretically, at least, it doesn't seem like switching should be necessary.
But, of course, I say this from the perspective of one who is not intimately
familiar with the code.


More information about the Rubygems-developers mailing list