[Rubygems-developers] Design notes for RubyGems 2

[Chad Fowler]

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 
> Gavin's
> (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 
>> 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!
>

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

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

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

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

Chad