[Rubygems-developers] Design notes for RubyGems 2
chad at chadfowler.com
Tue Jun 8 08:54:38 EDT 2004
On 8/6/2004, at 8:35 AM, Curt Hibbs wrote:
> 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
> (perhaps initially as a wrapper) and then refactor into that?
I guess I don't feel like refactoring needs a target. I'm afraid a
target would become a shoe-horn, vs a natural evolutionary progression.
>> 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
>> To me, that's why it doesn't really make sense to have a "Gem"
> Huh? To me that is precisely why its makes sense to have a Gem as an
I mean that it's an abstract thing that doesn't need to be concrete.
Making a concrete object out of the Gem is an attempt to take an
inherently abstract concept and use it as if it's a real Thing.
Sometimes that makes sense (and it's the first thing that OO designers
tend to do), but I don't think it does in this case. The spec is the
metadata and the files are..."File"s :)
My guess is that further refactoring of the current design would
improve the "process"-orientation of the code without making it more
>> What we probably need is to refactor and clean up some of our
>> 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.
I think "up" and "down" in these two cases refer to the same thing. I
think of ideal programs as being in 3(ish) layers:
top: scripting using a simple domain language that is expressed in Ruby
middle: Implementation of that domain language
bottom: OO API with components support this language
So, when I say refactor the top level, pushing things down into the
API, this is what I'm talking about.
>> My mind isn't shut, but I'm starting out not seeing a reason to
>> If we were starting from scratch, I'd be more likely to jump on
> Theoretically, at least, it doesn't seem like switching should be
> But, of course, I say this from the perspective of one who is not
> familiar with the code.
I'd be more likely to take Gavin's document as a set of good ideas and
try to incorporate them when they become the obvious solution to a
problem that comes up. I don't think setting them as a target for
refactoring or doing a complete redesign is warranted or advantageous
at this point.
I'd like to approach this without making the assumption that
"data"-oriented is better than "process"-oriented and talk more about
current limitations. So far, there hasn't been anything very difficult
to refactor, change, remove, or add, and I'm not saying this because I
wrote all this code (I didn't). The one difficult thing is abstracting
user interaction from the API to avoid STDIN/STDOUT coupling. I think
that's an inherently difficult thing to do without making an ugly,
Java-esque GUI API, but I'm sure starting over would help there simply
because the design could be made around this issue. That being said, I
don't think it's worth it.
So, let's hear about some specific issues with the current system
(other than obvious needs-a-clean-up stuff) and see what we can figure
More information about the Rubygems-developers