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



-- 
Best regards,
Igor Stasenko AKA sig.