How about a class comment that gives an overview of intended usage, plus an
example or two, and sketches the API?

pant, pant.

Eliot

On Wed, Dec 15, 2010 at 11:19 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Folks -
>
> To illustrate my point about Gofer being an API, here is an implementation
> of the same API. Gofer's little brother -called Goofy- provides an
> implementation of the Gofer API but it's a bit simpler and comes in a single
> class (with a total of 400 LOC or so). It passes most of the Gofer tests.
>
> The exercise was actually interesting since it points out several things
> that are just plain broken from the Monticello perspective. I just posted a
> fix for the first issue - a way to get versions and names in a consistent
> way from different repositories. Clearly a thing that should be in
> Monticello.
>
> Another interesting issue is some of the cleanup that is in Gofer and
> pretty much directly replicated in Goofy's #cleanoutWorkingCopy:
> #unloadWorkingCopy: and #unregisterRepositories:. These are all things that
> need to be folded into MCWorkingCopy but I'll leave that for another day
> since I'm a bit tired right now and don't want to accidentally break MC in
> the process :-)
>
> In any case, if you look at Goofy I think you'll see the API much more
> clearly. It's a good API, but it doesn't need to be spread out amongst some
> 20-something classes.
>
> Cheers,
>  - Andreas
>
> On 12/15/2010 9:54 AM, Andreas Raab wrote:
>
>> On 12/15/2010 9:21 AM, Chris Muller wrote:
>>
>>> One question that came to my mind last night: What does> 1000 lines
>>> of Gofer code bring to Monticello-loading that I can't already do with
>>> just Monticello? or with a couple of facade methods added to plain
>>> MC?
>>>
>>
>> I spent the evening yesterday to look at Gofer in detail and it is what
>> led me to say that Gofer is really an API to Monticello, not an
>> installer. First, there is nothing in there that should not be part of
>> Monticello proper; contrary to Installer and Metacello I would expect
>> all the stuff that is in Gofer to be readily available in Monticello
>> itself. Gofer is simply a good facade to Monticello with a useful API.
>>
>> Secondly, much of the code in Gofer comes from the "command pattern gone
>> wild" problem. Gofer simply overuses the command pattern. Every
>> operation is wrapped in a separate class without any need for doing so.
>> As a consequence, things that should be a simple "self foo" become
>> unnecessarily complex in creation, setup, and execution. If you would
>> take this out, it would reduce Gofer to 5 classes or so and the total
>> code size by a significant amount while improving clarity.
>>
>> As an API to Monticello, Gofer is very nice and we should standardize on
>> it. But as a "replacement" for Installer it's not even in the same
>> ballpark.
>>
>> Cheers,
>> - Andreas
>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101216/1730c71a/attachment.htm