I will just mention that for Metacello I found that I needed to extend 
Gofer in a couple of key areas and with just a couple of classes and 
overriding a method or two, I was able to "bend gofer" to my will:)

In my experience implementations that are written using only a few 
classes are more difficult to extend because the key assumptions are 
spread throughout the methods rather than isolated in classes ... you 
have to copy/modify/maintain a lot of code that is not related to what 
you are trying to accomplish...

I haven't looked at the goofy implementation to see how easy it would be 
to use from within Metacello I don't need to ... gofer works just fine 
for what I need:)

Dale

On 12/16/2010 02:10 PM, Igor Stasenko wrote:
> 2010/12/16 Janko Mivšek<janko.mivsek at eranova.si>:
>> Guys, for Thursday funny: "It is really goofy that some people do not
>> understand the price-value relationship of classes in object-oriented
>> systems." http://twitter.com/#!/renggli
>>
>> Well, I couldn't resist :)
>
> Me too.. me too.
> It would be good to hear arguments from other side here.
>
> Personally i don't care how many classes takes an implementation, if
> it not forcing me to learn more than i can swallow in order to start
> using it productively.
>
>> Janko
>>
>> On 16. 12. 2010 08:19, Andreas Raab 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
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Janko Mivšek
>> AIDA/Web
>> Smalltalk Web Application Server
>> http://www.aidaweb.si
>>
>>
>
>
>