How about a class comment that gives an overview of intended usage, plus an example or two, and sketches the API?<br><br><div>pant, pant.</div><div><br></div><div>Eliot</div><div><br><div class="gmail_quote">On Wed, Dec 15, 2010 at 11:19 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Folks -<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 :-)<br>
<br>
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.<br>
<br>
Cheers,<br>
- Andreas<br>
<br>
On 12/15/2010 9:54 AM, Andreas Raab wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/15/2010 9:21 AM, Chris Muller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One question that came to my mind last night: What does> 1000 lines<br>
of Gofer code bring to Monticello-loading that I can't already do with<br>
just Monticello? or with a couple of facade methods added to plain<br>
MC?<br>
</blockquote>
<br>
I spent the evening yesterday to look at Gofer in detail and it is what<br>
led me to say that Gofer is really an API to Monticello, not an<br>
installer. First, there is nothing in there that should not be part of<br>
Monticello proper; contrary to Installer and Metacello I would expect<br>
all the stuff that is in Gofer to be readily available in Monticello<br>
itself. Gofer is simply a good facade to Monticello with a useful API.<br>
<br>
Secondly, much of the code in Gofer comes from the "command pattern gone<br>
wild" problem. Gofer simply overuses the command pattern. Every<br>
operation is wrapped in a separate class without any need for doing so.<br>
As a consequence, things that should be a simple "self foo" become<br>
unnecessarily complex in creation, setup, and execution. If you would<br>
take this out, it would reduce Gofer to 5 classes or so and the total<br>
code size by a significant amount while improving clarity.<br>
<br>
As an API to Monticello, Gofer is very nice and we should standardize on<br>
it. But as a "replacement" for Installer it's not even in the same<br>
ballpark.<br>
<br>
Cheers,<br>
- Andreas<br>
<br>
<br>
</blockquote>
<br>
<br><br>
<br></blockquote></div><br></div>