Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

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

> 2010/12/16 Janko Mivšek<[hidden email]>:
>> 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
>>
>>
>
>
>

> On 12/16/2010 2:10 PM, Igor Stasenko wrote:
>>
>> 2010/12/16 Janko Mivšek<[hidden email]>:
>>>
>>> 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.
>
> Indeed. From my perspective there are some pretty straightforward rules for
> when creating additional classes is a good idea.
>
> For example, I am a big fan of Announcements, since they make the set of
> events that are part of an application explicit. Even though one can just
> use names (i.e., self signalEvent: #foo) having each event be a separate
> class is beneficial because a user who doesn't know what events exist, can
> find those, can find out where they are signaled, and how they are used.
>
> Or Exceptions. Another good use for having additional classes. Both for
> purposes of documentation (what exceptions exist) as well as for extending
> them. For example, I can add a subclass of ConnectionError in my application
> and generic handlers for ConnectionError in third party code will be able to
> catch the error correctly.
>
> Or the command pattern itself, which is extremely useful in many situations,
> like when you need to reason about bulk sets of method invocations (in undo
> for example).
>
> So there are indeed various reasons for when adding additional classes can
> be very, very beneficial. But let's not forget that there's a cost
> associated with it as well. If it were different, if there was really no
> cost associated with having a class, how about we make all of the 2000 Morph
> methods into commands? If there is no cost to it, then it must be
> beneficial, right?
>
> So yes, I understand that there's a cost-benefit ratio for adding additional
> classes. But if there's a good reason for these classes in Gofer, then I
> just don't see it. None of the rules for when additional classes are a good
> idea seem to apply. In which case Occam's razor wins.
>
> Now if I only could make that argument in 140 characters... but then no
> sensible argument has ever been made on Twitter and none ever will, so who
> cares.
>

> On 12/16/2010 4:37 PM, Dale Henrichs wrote:
>> 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...
>
> Generally speaking, yes. If you dump everything in a single class or two
> then you're going to end up in a mess. However, if most of your classes
> end up having a single method or two for no tangible benefit, there's a
> bad smell there as well.

>> Generally speaking, yes. If you dump everything in a single class or two
>> then you're going to end up in a mess. However, if most of your classes
>> end up having a single method or two for no tangible benefit, there's a
>> bad smell there as well.
>
> Exactly. Extremes are always bad. And both extremes lower the simplicity
> and therefore maintability of the code and specially, comprehendibility
> by newcommers. That's why also wanted to show with my code stats
> comparison between Aida, Seaside and Iliad:
>
> https://spreadsheets.google.com/ccc?key=0Atnb1W9vuq9ndG4wbUpxNXpKQnFZRlFyQXpHclhZa2c&hl=sl#gid=1
>
> >From "Methods in classes" distribution graph, then from number of
> packages and categories you can clearly see two schools of thought here.
>
> I of course claim that Aida "school of thought" with its balanced
> distribution of code between methods, classes, categories and packages
> is more comprehensible and therefore more simple.
>
> Best regards
> Janko
>
> --
> Janko Mivšek
> AIDA/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>
>

> Very cool. I just ran this on our code base:
>
> Code stats           Tweak       Croquet
> Nr of packages:         14            17
> Nr of categories        53            26
> Nr of classes:         297           241
> Nr of methods:        6168          6476
> lines of code:       36919         49063
> Avg methods/class:    20.7          26.8
> Avg lines/method:      5.9           7.5
>    
> Nr of test methods:      6           150
> % of commented methods: 50            53
> % of commented classes: 59            92
>
> (I'll ask if I can share the numbers on the Qwaq packages as well). One
> relevant note is that I don't have the Tweak test packages loaded which
> explains the absence of tests. Other than that it looks as if there's
> virtually no difference in terms of average length of methods (Tweak is
> a little lower probably because of auto-generated accessors) but it's
> amazing that the average length of Croquet (and Qwaq) methods is
> virtually identical to the average length of Aida and Seaside methods :-)
>
> One thing that was interesting to me was that when I ran the method
> distribution code I found that we have a significant number of classes
> with more than 50 methods (in the 10% range). In your comparison, there
> is nothing listed beyond 50 methods/class. Are there no classes with
> more methods in any of the frameworks, or did you prune them? What
> surprised me here was that the number is significantly higher than I
> expected; but it seems that there are usually one or two very large
> interfaces (CPlayer in Tweak for example carrying 400 methods) and I
> think it's not too uncommon to have a "handful" of classes that come in
> in the 50-100 methods range.