Re: [Pharo-project] [squeak-dev] Gofer versus Installer
Hi guys, Cross posted to Squeak and Pharo. On 14. 12. 2010 22:56, Ken G. Brown wrote:
Lukas maintains Gofer and there are reasons to use it: closer relationship with Pharo, contemporary MC integration (Metacello).
I can accept using Gofer in trunk, for things that require it like reading it's own scripts. But I don't want to see Installer go away... because of all the things Installer does that Gofer doesn't.
What if someone: 1. adds to Gofer loading from SqueakMap and other 2. then Lukas is kindly asked to rename it to the Installer. That way we will have a maintained installer with a meaningful name and everyone will be happy. Because we really need one and only one installer for both Squeak and Pharo. Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
On 12/15/2010 6:27 AM, Janko Mivšek wrote:
What if someone:
1. adds to Gofer loading from SqueakMap and other 2. then Lukas is kindly asked to rename it to the Installer.
That way we will have a maintained installer with a meaningful name and everyone will be happy. Because we really need one and only one installer for both Squeak and Pharo.
Slightly wrong. Gofer isn't an installer. Gofer is the API for Monticello. If you wanted to rename it you should rename it simply to "Monticello" and merge it with the MC core packages. Cheers, - Andreas
On 15 December 2010 17:46, Andreas Raab <andreas.raab@gmx.de> wrote:
On 12/15/2010 6:27 AM, Janko Mivšek wrote:
What if someone:
 1. adds to Gofer loading from SqueakMap and other  2. then Lukas is kindly asked to rename it to the Installer.
That way we will have a maintained installer with a meaningful name and everyone will be happy. Because we really need one and only one installer for both Squeak and Pharo.
Slightly wrong. Gofer isn't an installer. Gofer is the API for Monticello. If you wanted to rename it you should rename it simply to "Monticello" and merge it with the MC core packages.
+1 just had the same impression. Gofer looks like a fine-shaped MC frontend.
Cheers, Â - Andreas
-- Best regards, Igor Stasenko AKA sig.
I think my suggestion would be more palatable to folks concerned about tidiness: - Strip Installer of all features that can be handled by Gofer. - Make Installer USE Gofer for those things that Gofer does (Monticello packages). - That way folks like Miguel can have only Gofer loaded, old fogies like me can have Installer+Gofer loaded. 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? 2010/12/15 Janko Mivšek <janko.mivsek@eranova.si>:
Hi guys,
Cross posted to Squeak and Pharo.
On 14. 12. 2010 22:56, Ken G. Brown wrote:
Lukas maintains Gofer and there are reasons to use it: closer relationship with Pharo, contemporary MC integration (Metacello).
I can accept using Gofer in trunk, for things that require it like reading it's own scripts. But I don't want to see Installer go away... because of all the things Installer does that Gofer doesn't.
What if someone:
 1. adds to Gofer loading from SqueakMap and other  2. then Lukas is kindly asked to rename it to the Installer.
That way we will have a maintained installer with a meaningful name and everyone will be happy. Because we really need one and only one installer for both Squeak and Pharo.
Best regards Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
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
participants (4)
-
Andreas Raab -
Chris Muller -
Igor Stasenko -
Janko Mivšek