[Rubygems-developers] Design notes for RubyGems 2
chad at chadfowler.com
Tue Jun 8 19:51:35 EDT 2004
On 8/6/2004, at 12:58 PM, Curt Hibbs wrote:
> Gavin Sinclair wrote:
> [snip, snip, snip]
>> The benefits of a well-constructed, well-documented system seems quite
>> advantageous to me. And since I approach all development with the
>> mentality that the first cut should be thrown away, I see a complete
>> redesign as very much warranted as some point, and my gut feeling is
>> we've reached it.
>> But I know I'm not going to persuade anyone on gut feeling alone, so
>> I'll see if I can find some more specific deficiencies. To be
>> honest, I
>> looked through the planned feature list on the wiki and didn't see
>> anything jump out at me as impossible or really difficult. But if the
>> code was well presented and well factored, I'd probably have
>> implemented half of them by now.
> I won't belabor the point by strewing my thoughts amongst all the text
> I snipped, just suffice it to say that I really agree with everything
> Gavin has said and I think he sums it up very well in the first
> that I kept above.
That sentence is universally true. It's impossible not to agree with.
What I can't agree with is that
> Well-defined implementations of simple abstractions are *extremely*
> enabling, both internally in its implementation and externally for
> applications. It makes the underlying code simple to navigate and
> which, in turn, makes it easy to modify and add features. The hiding of
> complexity behind simple abstractions allows the code base to grow
> undermining its understandability.
I agree. This is how most of us code. But, I don't believe that the
"real world" elements that we use in conversation are always the best
abstractions. "Gem" is the best example of something that sounds
concrete when we talk about it but doesn't add much value as a class in
Ruby. However, if you want this class, its elements are: gemid,
specification, and data. "gemid" (which I wouldn't make a class out
of, personally) is the combination of "name" and "version" (both
available on the specification), "specification" is the current
"Specification" class, and "data" is proposed to be a single string
containing the data of the rubygem. We currently have a smarter class
called "Format", which provides convenient access to the data of a gem.
It is one of the major things that was factored out early after
The more I look at it, the more I realize that most of this design is
already done. The classes have different names and are arranged
differently, but most of what Gavin has documented is already there.
They could be tied together in different ways and factored out in some
cases (Repository from the Installers, maybe?).
This is why I'm looking for specifics. Anything that makes the code
truly easier to deal with would be great. Perhaps there would be some
front end to Specification and Format. Right now, that front end is
Validator and Installer ("processes").
> Finally, the processes are embedded with the objects that encapsulate
> relevant data. I can't think of a cleaner representation.
Sometimes it makes more sense to separate the data holders from the
things that operate on them. Sometimes it doesn't. I wouldn't
generalize and say that either is always cleaner or clearer.
More information about the Rubygems-developers