In the beginning, Metacello had an abstract class for configurations. but it became a chicken and egg problem (you had to get Metacello loaded into the image before you could work with a configuration). The current scheme was invented to get around that particular problem. Adding a method to Object only works if Squeak adds the method. If changes are to be made to the base. If changes are going to be made to the base then an abstract class should be added and be done with. I guess it is worth mentioning that the ConfigurationOf classes are really just smart versions of XML ... In other words all of the information in a configuration can be represented in a text file ... using Smalltalk means that every image has a built in configuration file editor and a built in configuration file compiler. Using Smalltalk means that there Monticello repositories that can be used to share and distribute configurations... Are we reaching the point where our effort should go into creating tools for building/managing/storing configuration files? Which would require that some bootstrapping code be loaded into each of the Smalltalks for Metacello support... I mention this because I think that there will be pain involved in changing the "format" of Metacello configurations. Right now, Metacello is basically self-contained and non-intrusive at the cost of a somewhat ugly configuration creation process... Should we consider the fact that if we are going to experience pain, maybe it should be the "last pain." In other words, lets make a change that is aimed at the "final format" for Metacello configurations rather than an intermediate format that will be used for awhile and then changed again... Dale Mariano Martinez Peck wrote:
On Mon, Aug 23, 2010 at 6:32 PM, Dale Henrichs <dhenrich@vmware.com <mailto:dhenrich@vmware.com>> wrote:
Is Gofer preloaded in Squeak?
The #ensureMetacello is intended to work on all platforms. For earlier versions of Pharo, gofer had to be loaded before Metacello could be loaded and if Gofer isn't preloaded in Squeak, then we still have that problem.
I guess I should say that _I_ have that problem, because I am interested in configurations that can be used with any Smalltalk that supports Monticello:)
I want to say a couple of things:
0) Objective? Don't need to write #ensureMetacello in each conf as it is 99% times the same and we don't want to update each conf to the latest ensureMetacello that is in the wiki
1) I don't know if Gofer works or is preloaded in Squeak. But what I really think is that if Squeak wants to "officially" supports Metacello, then they should be ready to integrate things. Ok, maybe not a complete package like Gofer, but at least some messages or something that would be of help.
2) What about providing a solution that works for different cases. For example, the following come to my mind (of course, hacky, but you can make it better for sure):
- we can creat Object>>ensureMetacello in squeak, phaor, gemstone. Okokoko, puting those methods in Object sucks..but if you have a better idea :)
Then, in Pharo we can implement it this way:
Object >> ensureMetacello Gofer ensureMetacelloCore
Gofer >> ensureMetacelloCore
"Bootstrap Gofer (if necessary), load latest mcz file for ConfigurationOfMetacello (using old Gofer API), then load the latest version of Metacello itself."
Smalltalk at: #MetacelloProject ifAbsent: [ | error | "list of repositories to try, in case primary repository is not accessible" (Array with: 'http://www.squeaksource.com/MetacelloRepository' with: 'http://seaside.gemstone.com/ss/metacello') do: [:repositoryUrl | ([ Smalltalk at: #Gofer ifAbsent: [ "Current version of Gofer from which to bootstrap - as of 1.0-beta.21" self bootstrapPackage: 'Gofer-Core-lr.115' from: repositoryUrl ]. Smalltalk at: #Gofer ifPresent: [:goferClass | | gofer | gofer := goferClass new url: repositoryUrl; yourself. [ gofer addPackage: 'ConfigurationOfMetacello' ] on: Warning do: [:ex | ex resume ]. gofer load ]] on: Error do: [ :ex | error := ex. Transcript cr;
show: 'failed ensureMetacello: ';
show: ex description printString;
show: '...retrying'. "try again" ex return: nil ]) ~~ nil ifTrue: [ "load 'default' group of Metacello" (Smalltalk at: #ConfigurationOfMetacello) perform: #load. ^self ]]. "shouldn't get here unless the load failed ... throw an error" self error: 'retry with alternate repository failed: ', error description printString ]
here we can even remove the ifFalse if Gofer is not present...since in Pharo it is present.
So...in Pharo, if you have specified ensureMetacello in your Conf...then perfect. That one will be use. If you don't want to implement it and let it as default (like 99% of the cases), self ensureMetacello would be object, which will delegate to Gofer, who will load the Metacello Core.
In Squeak, it can be as it is now. They can use they own ensureMetacello (the difference here is that they HAVE to implement such method as they don't have it in they own image). Maybe they can even implement ensureMetacello in object using Installer or whatever they have in the core to load monticello packages.
If #ensureMetacello has to be updated we only need to change Gofer>>ensureMetacello and not all the confs.
Those who need to load a different Metacello version, different groups, or from different repo, they just implement #ensureMetacello in their OWN conf and that's all. For example, I can do this in ConfigurationOfPharo as I need not only core, but UI and tests.
Now that I am thinking it...my "idea" is outside Metacello. The problem is that if someone writes a conf, without #ensureMetacello, it will load fine in Pharo but will fail in Squeak.
what do you think?