Minimal base image Metacello presence for GemStone, Pharo, and Squeak

I've been thinking about the best way for Metacello to have a "minimal presence" in the GemStone, Pharo and Squeak base images. A while ago Colin[1] mentioned that The Squeak board would consider the possiblity of including support for Metacello in the base Squeak image (after the 4.3 release), but I wasn't exactly sure of what level of base image support was practical.

As part of the process for developing 1.0-beta.32, I reviewed Ben Coman's post[2] on "Newbie observations on use of Metacello" (Ben, thanks for a well-writting post) and suddenly things clicked...

There are three basic issues that I think need to be addressed with the "minimal presence":

  - Common superclass for ConfigurationOf classes.
      The practice of copying a class  template is not the best example of proper Smalltalk.
  - Bootstrapping Metacello.
      There needs to be a clean way of triggering the bootstrap of Metacello as well as a
      clean way for unloading Metacello from the image, if desired.
  - Common scripting API
      Metacello load scripts must be platform independent. It doesn't make sense to use Installer
      for Squeak and Gofer for Pharo and GemStone. Including a Metacello scripting API included
      in the base image solves that problem.

I've had an example of the common superclass for configurations for a while now (MetacelloBaseConfiguration in the Metacello-Base package, available since about 1.0-beta.28).

For scripting, I think it makes sense to create a class (named Metacello) that implements a scripting API designed specifically for Metacello. The API would include the basic functionality from GoferProjectLoader as well as additional functionality for creating and editting configurations programmatically. In the interest of keeping a "minimal presence" the Metacello class would be implemented with a bare minimum of methods and would bootstrap Metacello when necessary.

I have some ideas for what the scripting API would look like, but I will make those suggestions in a separate email so that we can cleanly separate the discussions.

In my mind, the common scripting API (Ben, thanks again for the "kick in the butt") and common superclass forms the perfect minimal presence, so I'm interested in your thoughts.

Dale

[1] http://forum.world.st/Bootstrapping-tp4167088p4167601.html
[2] http://forum.world.st/Newbie-observations-on-use-of-Metacello-td4212946.html

--
Mariano
http://marianopeck.wordpress.com

Ben,

Thanks for the additional feedback, I've create Issue 174[1] with your changes suggestion ... I _am_ thinking along the lines of expanding the Scripting API to do more than just load configurations ... configuration comparison is a good idea ...

I've budgeted myself the two classes and as I've worked through the proposed API, I think that a set of methods present as part of the "minimal presence" is probably a good idea as it avoids the "selector not implemented issue" as well as providing a bit of documentation as to what methods can be used in a script..

Thanks for the feedback,

Dale

[1] http://code.google.com/p/metacello/issues/detail?id=174

----- Original Message -----
| From: "Ben Coman" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Cc: [hidden email], "Stéphane Ducasse" <[hidden email]>, [hidden email], "Esteban
| Lorenzano" <[hidden email]>, "Mariano Martinez Peck" <[hidden email]>
| Sent: Friday, January 27, 2012 11:54:23 AM
| Subject: Re: Minimal base image Metacello presence for  GemStone, Pharo, and Squeak
|
| I'm not qualified to comment on policy matters, but I'm glad its
| generated discussion and I have a couple of additional thoughts.
|
| Dale Henrichs wrote:
| > I've been thinking about the best way for Metacello to have a
| > "minimal presence" in the GemStone, Pharo and Squeak base images.
| > A while ago Colin[1] mentioned that The Squeak board would
| > consider the possiblity of including support for Metacello in the
| > base Squeak image (after the 4.3 release), but I wasn't exactly
| > sure of what level of base image support was practical.
| >
| > As part of the process for developing 1.0-beta.32, I reviewed Ben
| > Coman's post[2] on "Newbie observations on use of Metacello" (Ben,
| > thanks for a well-writting post) and suddenly things clicked...
| >
| > There are three basic issues that I think need to be addressed with
| > the "minimal presence":
| >
| >   - Common superclass for ConfigurationOf classes.
| >       The practice of copying a class  template is not the best
| >       example of proper Smalltalk.
| >   - Bootstrapping Metacello.
| >       There needs to be a clean way of triggering the bootstrap of
| >       Metacello as well as a
| >       clean way for unloading Metacello from the image, if desired.
| >   - Common scripting API
| >       Metacello load scripts must be platform independent. It
| >       doesn't make sense to use Installer
| >       for Squeak and Gofer for Pharo and GemStone. Including a
| >       Metacello scripting API included
| >       in the base image solves that problem.
| >  
| If an existing ConfigurationOfXXX is downloaded to Squeak using
| Installer rather than Gopher, then one of the first things that
| 'ConfigurationOfXXX  class>>ensureMetacello' does is load Gopher.  So
| the result for Squeak is no different whether Gopher is loaded by a
| built-in bootstrap or by the bootstrap in each ConfigurationOfXXX.
| Gopher is already effectively used for Metacello on all platforms.
|
| The Metacello scripting API might be more about querying package
| state.
| It seems that using only the Monticello Browser you can only see
| 'Changes' of the ConfigurationOfXXX file, rather than 'Changes' of
| every
| package that would load.  Perhaps the Metacello scripting could
| simulate
| a load to preview all changes that would be made by the whole
| package.
| Also it might indicate where two packages refer to different versions
| of
| the same Monticello file as well as report the current "version"
| loaded
| - being different from the ConfigurationOfXXX-aaa.22.mcz.
| > I've had an example of the common superclass for configurations for
| > a while now (MetacelloBaseConfiguration in the Metacello-Base
| > package, available since about 1.0-beta.28).
| >
| > For scripting, I think it makes sense to create a class (named
| > Metacello) that implements a scripting API designed specifically
| > for Metacello. The API would include the basic functionality from
| > GoferProjectLoader as well as additional functionality for
| > creating and editting configurations programmatically. In the
| > interest of keeping a "minimal presence" the Metacello class would
| > be implemented with a bare minimum of methods and would bootstrap
| > Metacello when necessary.
| >
| > I have some ideas for what the scripting API would look like, but I
| > will make those suggestions in a separate email so that we can
| > cleanly separate the discussions.
| >
| > In my mind, the common scripting API (Ben, thanks again for the
| > "kick in the butt") and common superclass forms the perfect
| > minimal presence, so I'm interested in your thoughts.
| >
| > Dale
| >
| > [1] http://forum.world.st/Bootstrapping-tp4167088p4167601.html
| > [2]
| > http://forum.world.st/Newbie-observations-on-use-of-Metacello-td4212946.html
| >
| >  
| This might be a rough practice, but I was thinking that the most
| minimal
| presence would be...
| Metacello class>>doesNotUnderstand
|     "copy the whole of the  ensureMetacello  method here"
|     "then resend the received message"
|
| While solving the chicken/egg problem within each ConfigurationOfXXX
| is
| elegant, in practice having that minimal built-in bootstrap would
| have
| the same effect.   With the footprint of only a single class and
| single
| method, it might also be easier for this Metacello bootstrap to be
| included in any new platforms.
|
| cheers, Ben
|
|
|
|
|

Mariano,

Exactly ... Right now I'm working through the permutations for an API that replaces the "standard Metacello load script":

  Gofer new
    squeaksource: 'MetacelloRepositorty';
    package: 'ConfigurationOfSeaside30';
    load.
  ((Smalltalk at: #ConfigurationOfSeaside30) version: '3.0.6') load: #('Base').

with something like the following:

  Metacello new
    project: 'Seaside30';
    squeaksource: 'MetacelloRepository';
    version: '3.0.6;
    load: #('Base').

I am departing from a strict reuse of the GoferProjectLoader API and straying closer to the Gofer-style API ... I think that basic API can be completely implemented in a single class while the execution of the operations will take "all of Metacello"...

Dale


----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Cc: [hidden email], "Stéphane Ducasse" <[hidden email]>, [hidden email], "Ben Coman"
| <[hidden email]>, "Esteban Lorenzano" <[hidden email]>
| Sent: Friday, January 27, 2012 12:29:15 PM
| Subject: Re: Minimal base image Metacello presence for GemStone, Pharo, and Squeak
|
|
|
|
| On Fri, Jan 27, 2012 at 7:14 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| I've been thinking about the best way for Metacello to have a
| "minimal presence" in the GemStone, Pharo and Squeak base images. A
| while ago Colin[1] mentioned that The Squeak board would consider
| the possiblity of including support for Metacello in the base Squeak
| image (after the 4.3 release), but I wasn't exactly sure of what
| level of base image support was practical.
|
| As part of the process for developing 1.0-beta.32, I reviewed Ben
| Coman's post[2] on "Newbie observations on use of Metacello" (Ben,
| thanks for a well-writting post) and suddenly things clicked...
|
| There are three basic issues that I think need to be addressed with
| the "minimal presence":
|
| - Common superclass for ConfigurationOf classes.
| The practice of copying a class template is not the best example of
| proper Smalltalk.
| - Bootstrapping Metacello.
| There needs to be a clean way of triggering the bootstrap of
| Metacello as well as a
| clean way for unloading Metacello from the image, if desired.
| - Common scripting API
| Metacello load scripts must be platform independent. It doesn't make
| sense to use Installer
| for Squeak and Gofer for Pharo and GemStone. Including a Metacello
| scripting API included
| in the base image solves that problem.
|
|
|
| - It is not important but when I want to install something with
| metacello and docuemnt the code to do it, , for example:
|
| Gofer it
| url: ' http://ss3.gemstone.com/ss/MarianoBuilder ';
| package: 'MarianoBuilder';
| load.
|
| (Smalltalk at: #ConfigurationOfMariano) perform: #loadMarea
|
| If I want to share that script or to put it in a website, I hate 2
| things:
| 1) have to use Smalltalk at: #COnfigurationOfXX because the class is
| yet not present:
| 2) I hate to do the perform because otherwise the horrible compiler
| popup will shout "ar you sure it is #load ??" ... "yes, idiot, can
| you imagine that #project would bring stuff that implements #load ?
| " hhahaha
|
| So...I would like to share a script that dosn't have any of those 2
| problems. For example:
|
| Metacello loadProjectNamed: 'Marea'
| and that's all.
|
|
|
| I've had an example of the common superclass for configurations for a
| while now (MetacelloBaseConfiguration in the Metacello-Base package,
| available since about 1.0-beta.28).
|
| For scripting, I think it makes sense to create a class (named
| Metacello) that implements a scripting API designed specifically for
| Metacello. The API would include the basic functionality from
| GoferProjectLoader as well as additional functionality for creating
| and editting configurations programmatically.
|
| +1 to reuse the API of GoferProjectLoader. Moreover, I guess
| Metacello class will you kind of Strategy/pattern that then
| delegates to Gofer/Installer/whatever. So... for pharo at least I
| think you can directly reuse also the CODE of GoferProejctLoader and
| use that rather than Gofer directly.
| Maybe it is even easier to adapt ProjectLoader so that it uses
| different installers and from Metacello you use that ?
| Because in such a case ProjectLoader would be helpful even outside
| Metacello. I imagine kind of scripting facade.
|
|
| In the interest of keeping a "minimal presence" the Metacello class
| would be implemented with a bare minimum of methods and would
| bootstrap Metacello when necessary.
|
| I have some ideas for what the scripting API would look like, but I
| will make those suggestions in a separate email so that we can
| cleanly separate the discussions.
|
| In my mind, the common scripting API (Ben, thanks again for the "kick
| in the butt") and common superclass forms the perfect minimal
| presence, so I'm interested in your thoughts.
|
| Dale
|
| [1] http://forum.world.st/Bootstrapping-tp4167088p4167601.html
| [2]
| http://forum.world.st/Newbie-observations-on-use-of-Metacello-td4212946.html
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

Am 2012-01-27 um 19:14 schrieb Dale Henrichs:

> I've been thinking about the best way for Metacello to have a "minimal presence" in the GemStone, Pharo and Squeak base images. A while ago Colin[1] mentioned that The Squeak board would consider the possiblity of including support for Metacello in the base Squeak image (after the 4.3 release), but I wasn't exactly sure of what level of base image support was practical.

I like the idea,
however, can you give me an idea of memory/complexity increase
a "minimal presence" would give for either the platforms?

Best
        -Tobias

Tobias,

Two classes, one category, maybe 100 (mostly very small) methods tops, depending upon the eventual size of the Metacello scripting API... There'll probably be a couple of class comments and I expect to include some HelpBrowser documentation methods, as well...

The common superclass for configurations has about 10 methods right now.

The scripting class will record information in a collection. When a command is encountered, the Metacello code base will be loaded into the image and the command will be forwarded to a scripting engine for execution. The collection will likely be an OrderedCollection of Associations (selector and argument), so there's no need for any supporting classes.

Pretty dang minimal:)

Dale

----- Original Message -----
| From: "Tobias Pape" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, January 28, 2012 5:11:26 AM
| Subject: Re: [Metacello] Minimal base image Metacello presence for  GemStone, Pharo, and Squeak
|
|
| Am 2012-01-27 um 19:14 schrieb Dale Henrichs:
|
| > I've been thinking about the best way for Metacello to have a
| > "minimal presence" in the GemStone, Pharo and Squeak base images.
| > A while ago Colin[1] mentioned that The Squeak board would
| > consider the possiblity of including support for Metacello in the
| > base Squeak image (after the 4.3 release), but I wasn't exactly
| > sure of what level of base image support was practical.
|
| I like the idea,
| however, can you give me an idea of memory/complexity increase
| a "minimal presence" would give for either the platforms?
|
| Best
| -Tobias

Dale Henrichs wrote

I've been thinking about the best way for Metacello to have a "minimal presence" in the GemStone, Pharo and Squeak base images

How's this coming, Dale? This would be great...

Sean

Very well ... I'm sitting at 3 classes:

  Metacello                          - scripting interface
  MetacelloBaseConfiguration         - common superclass for ConfigurationOf
  MetacelloBaseBaselineConfiguration - common superclass for BaselineOf

Still working my way through the scripting API ... #get and #load are basically done and today I was just going to sketch out the remaining tasks[1] before asking for volunteers to take it for a spin:)

Dale

[1] https://github.com/dalehenrich/metacello-work/issues?state=open


----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, May 19, 2012 11:23:45 AM
| Subject: [Metacello] Re: Minimal base image Metacello presence for  GemStone, Pharo, and Squeak
|
|
| Dale Henrichs wrote
| >
| > I've been thinking about the best way for Metacello to have a
| > "minimal
| > presence" in the GemStone, Pharo and Squeak base images
|
| How's this coming, Dale? This would be great...
|
| Sean
|
| --
| View this message in context:
| http://forum.world.st/Minimal-base-image-Metacello-presence-for-GemStone-Pharo-and-Squeak-tp4334269p4630865.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

I was just going to sketch out the remaining tasks[1] before asking for volunteers to take it for a spin:)

Count me in! I can't wait because this will eliminate a lot of problems (esp. with new users), like obsolete class-side code in configs!

Dale Henrichs wrote

  Metacello                          - scripting interface

 I didn't know the scripting interface would be included. Very cool...

Thanks for all the work you are doing. The cypress & git stuff is esp. exciting :)

Sean

Thanks Sean ...

I think that the scripting API is crucial for simplifying the use of Metacello for users ... no platform specific load scripts (Installer vs. Gofer) and no need to try to even use class-side methods anymore.

I will also include Cypress/Github support in this release...as the scripting API plays an important role there as well ...

Dale
----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, May 19, 2012 2:00:05 PM
| Subject: [Metacello] Re: Minimal base image Metacello presence for GemStone, Pharo, and Squeak
|
|
| Dale Henrichs wrote
| >
| > I was just going to sketch out the remaining tasks[1] before asking
| > for
| > volunteers to take it for a spin:)
| >
|
| Count me in! I can't wait because this will eliminate a lot of
| problems
| (esp. with new users), like obsolete class-side code in configs!
|
|
| Dale Henrichs wrote
| >
| >   Metacello                          - scripting interface
| >
|
|  I didn't know the scripting interface would be included. Very
|  cool...
|
| Thanks for all the work you are doing. The cypress & git stuff is
| esp.
| exciting :)
|
| Sean
|
| --
| View this message in context:
| http://forum.world.st/Minimal-base-image-Metacello-presence-for-GemStone-Pharo-and-Squeak-tp4334269p4630897.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote:
> Very well ... I'm sitting at 3 classes:
>
>   Metacello                          - scripting interface
>   MetacelloBaseConfiguration         - common superclass for ConfigurationOf
>   MetacelloBaseBaselineConfiguration - common superclass for BaselineOf
>  

Disclaimer: My This comment here is made out of context from knowing
your architecture...
However Metacello"BaseBaseline"Configuration is a bit awkward.  What is
the requirement for the use of the first 'base' ?  Can it be left out
completely? (I guess not since that would have been the default original
class name), or would the word 'root' provide the same semantics?
MetacelloRootConfiguration
MetacelloRootBaselineConfiguration

cheers -ben

Good point:)

----- Original Message -----
| From: "Ben Coman" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, May 19, 2012 3:18:40 PM
| Subject: Re: [Metacello] Re: Minimal base image Metacello presence for  GemStone, Pharo, and Squeak
|
| Dale Henrichs wrote:
| > Very well ... I'm sitting at 3 classes:
| >
| >   Metacello                          - scripting interface
| >   MetacelloBaseConfiguration         - common superclass for
| >   ConfigurationOf
| >   MetacelloBaseBaselineConfiguration - common superclass for
| >   BaselineOf
| >  
|
| Disclaimer: My This comment here is made out of context from knowing
| your architecture...
| However Metacello"BaseBaseline"Configuration is a bit awkward.  What
| is
| the requirement for the use of the first 'base' ?  Can it be left out
| completely? (I guess not since that would have been the default
| original
| class name), or would the word 'root' provide the same semantics?
| MetacelloRootConfiguration
| MetacelloRootBaselineConfiguration
|
| cheers -ben
|
| > Still working my way through the scripting API ... #get and #load
| > are basically done and today I was just going to sketch out the
| > remaining tasks[1] before asking for volunteers to take it for a
| > spin:)
| >
| > Dale
| >
| > [1] https://github.com/dalehenrich/metacello-work/issues?state=open
| >
| >
| > ----- Original Message -----
| > | From: "Sean P. DeNigris" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Saturday, May 19, 2012 11:23:45 AM
| > | Subject: [Metacello] Re: Minimal base image Metacello presence
| > | for  GemStone, Pharo, and Squeak
| > |
| > |
| > | Dale Henrichs wrote
| > | >
| > | > I've been thinking about the best way for Metacello to have a
| > | > "minimal
| > | > presence" in the GemStone, Pharo and Squeak base images
| > |
| > | How's this coming, Dale? This would be great...
| > |
| > | Sean
| > |
| > | --
| > | View this message in context:
| > | http://forum.world.st/Minimal-base-image-Metacello-presence-for-GemStone-Pharo-and-Squeak-tp4334269p4630865.html
| > | Sent from the Metacello mailing list archive at Nabble.com.
| > |
| >
| >  
|
|

Dale Henrichs wrote

I will also include Cypress/Github support in this release...as the scripting API plays an important role there

Wow! You've been busy :) The scripting API looks *very* nice...

The biggest unresolved issue I see with the way Metacello is being used (and one you've talked about) is that there's no clearinghouse for configs, which allows for the following imaginary nightmare scenario... there's a project on SqS, and someone makes a config, but doesn't have write access, so they make a config and put it in MetacelloRepository, but then the project maintainer makes a different one from scratch (with the same exact name of course) and puts it with the project, and then maybe Pharo makes their own (same name, different spec) and puts it in RepoForPharoXxx...

It seems there needs to be one and only one master, that is copied to wherever else it might be useful.

Sean

Ah yes ... the lookup aspect ... I'm glad that you've mentioned that ... I've got a `find` command listed in the api spec[1],  but I passed over it for inclusion in the first pass ... now that you mention it, I'll push it to the forefront...

The basic idea is that there will be a "search path" for finding configurations. The default "search path" will be dialect dependent, so Pharo/Squeak/Gemstone can define the initial search path. Each version of a platform can have a search path.

Users can than override or extend the search path for themselves.

I don't want to enforce "a one and only master", because I think that flexibility is an important factor (your project requires come changes that aren't accepted by the maintainers of the project and you need to "fork").

But I agree that there should be a standard mechanism for finding configurations so that folks don't have to figure out where to look.

For Git projects, the BaselineOf will be "embedded in the repository" and copying the BaselineOf around won't make sense, but the ConfigurationOf is intended to be distributed ....

Dale

[1] https://github.com/dalehenrich/MetacelloScriptingApiSpec/wiki/Commands

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, May 19, 2012 3:38:16 PM
| Subject: [Metacello] Re: Minimal base image Metacello presence for GemStone, Pharo, and Squeak
|
|
| Dale Henrichs wrote
| >
| > I will also include Cypress/Github support in this release...as the
| > scripting API plays an important role there
|
| Wow! You've been busy :) The scripting API looks *very* nice...
|
| The biggest unresolved issue I see with the way Metacello is being
| used (and
| one you've talked about) is that there's no clearinghouse for
| configs, which
| allows for the following imaginary nightmare scenario... there's a
| project
| on SqS, and someone makes a config, but doesn't have write access, so
| they
| make a config and put it in MetacelloRepository, but then the project
| maintainer makes a different one from scratch (with the same exact
| name of
| course) and puts it with the project, and then maybe Pharo makes
| their own
| (same name, different spec) and puts it in RepoForPharoXxx...
|
| It seems there needs to be one and only one master, that is copied to
| wherever else it might be useful.
|
| Sean
|
| --
| View this message in context:
| http://forum.world.st/Minimal-base-image-Metacello-presence-for-GemStone-Pharo-and-Squeak-tp4334269p4630926.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

I don't want to enforce "a one and only master"

I defer to your judgement. I'm just most afraid of http://a.url.com/ConfigurationOfXxx defining version 1.3, and http://b.url.com/ConfigurationOfXxx defining version 1.3, that is unrelated to a's... imagine the confusion...

Although, I guess what you're saying is that there will be much less of people manually hunting around for configs; their Smalltalk variant will do the lookup automatically, which should find and load the right thing.

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Friday, May 25, 2012 6:36:54 PM
| Subject: [Metacello] Re: Minimal base image Metacello presence for GemStone, Pharo, and Squeak
|
|
| Dale Henrichs wrote
| >
| > I don't want to enforce "a one and only master"
|
| I defer to your judgement. I'm just most afraid of
| http://a.url.com/ConfigurationOfXxx defining version 1.3, and
| http://b.url.com/ConfigurationOfXxx defining version 1.3, that is
| unrelated
| to a's... imagine the confusion...

This is the downside of distributed version control, in general. With distributed version control the packages/repositories are portable, for good reasons. You always have to consider the source. Caveat emptor is the rule.

|
| Although, I guess what you're saying is that there will be much less
| of
| people manually hunting around for configs; their Smalltalk variant
| will do
| the lookup automatically, which should find and load the right thing.

That's the idea. I'm building a lookup path into the scripting api and we'll see where that takes us, once it goes into general usage.


| --
| View this message in context:
| http://forum.world.st/Minimal-base-image-Metacello-presence-for-GemStone-Pharo-and-Squeak-tp4334269p4631890.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Ben, et.al.,

I am considering changing the names of the two classes (MetacelloBaseConfiguration and MetacelloBaseBaselineConfiguration) to:

  ConfigurationOf and BaselineOf

or:

  AbstractConfigurationOf and AbstractBaselineOf

What do you think?

Dale

----- Original Message -----
| From: "Ben Coman" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, May 19, 2012 3:18:40 PM
| Subject: Re: [Metacello] Re: Minimal base image Metacello presence for  GemStone, Pharo, and Squeak
|
| Dale Henrichs wrote:
| > Very well ... I'm sitting at 3 classes:
| >
| >   Metacello                          - scripting interface
| >   MetacelloBaseConfiguration         - common superclass for
| >   ConfigurationOf
| >   MetacelloBaseBaselineConfiguration - common superclass for
| >   BaselineOf
| >  
|
| Disclaimer: My This comment here is made out of context from knowing
| your architecture...
| However Metacello"BaseBaseline"Configuration is a bit awkward.  What
| is
| the requirement for the use of the first 'base' ?  Can it be left out
| completely? (I guess not since that would have been the default
| original
| class name), or would the word 'root' provide the same semantics?
| MetacelloRootConfiguration
| MetacelloRootBaselineConfiguration
|
| cheers -ben
|
| > Still working my way through the scripting API ... #get and #load
| > are basically done and today I was just going to sketch out the
| > remaining tasks[1] before asking for volunteers to take it for a
| > spin:)
| >
| > Dale
| >
| > [1] https://github.com/dalehenrich/metacello-work/issues?state=open
| >
| >
| > ----- Original Message -----
| > | From: "Sean P. DeNigris" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Saturday, May 19, 2012 11:23:45 AM
| > | Subject: [Metacello] Re: Minimal base image Metacello presence
| > | for  GemStone, Pharo, and Squeak
| > |
| > |
| > | Dale Henrichs wrote
| > | >
| > | > I've been thinking about the best way for Metacello to have a
| > | > "minimal
| > | > presence" in the GemStone, Pharo and Squeak base images
| > |
| > | How's this coming, Dale? This would be great...
| > |
| > | Sean
| > |
| > | --
| > | View this message in context:
| > | http://forum.world.st/Minimal-base-image-Metacello-presence-for-GemStone-Pharo-and-Squeak-tp4334269p4630865.html
| > | Sent from the Metacello mailing list archive at Nabble.com.
| > |
| >
| >  
|
|

Dale,

Bernardo,

Thanks for the feedback.

For names opinion is about all we have (once we've gotten past uniqueness).

I didn't bat an eye with the original names, so I value my opinion least of all:)

Dale

----- Original Message -----
| From: "Bernardo Ezequiel Contreras" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, May 30, 2012 12:06:11 PM
| Subject: Re: [Metacello] Re: Minimal base image Metacello presence for GemStone, Pharo, and Squeak
|
| Dale,
|
|
| Just an opinion, I prefer the names ConfigurationOf and BaselineOf
| because they are short.
|
| The names AbstractConfigurationOf and AbstractBaselineOf could give
| you some problems in the future if they'll become concrete classes.
| And they are too long.
|
|
| For more info,
| http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&printTitle=Do_not_use_Abstract_as_part_of_the_class_name&entry=3321089957
|
|
|
|
| Remember just an opinion.
|
|
|
|
|
| On Wed, May 30, 2012 at 2:23 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Ben, et.al .,
|
| I am considering changing the names of the two classes
| (MetacelloBaseConfiguration and MetacelloBaseBaselineConfiguration)
| to:
|
| ConfigurationOf and BaselineOf
|
| or:
|
| AbstractConfigurationOf and AbstractBaselineOf
|
| What do you think?
|
| Dale
|
|
| ----- Original Message -----
| | From: "Ben Coman" < [hidden email] >
| | To: [hidden email]
|
| | Sent: Saturday, May 19, 2012 3:18:40 PM
|
|
| | Subject: Re: [Metacello] Re: Minimal base image Metacello presence
| | for GemStone, Pharo, and Squeak
| |
| | Dale Henrichs wrote:
| | > Very well ... I'm sitting at 3 classes:
| | >
| | > Metacello - scripting interface
| | > MetacelloBaseConfiguration - common superclass for
| | > ConfigurationOf
| | > MetacelloBaseBaselineConfiguration - common superclass for
| | > BaselineOf
| | >
| |
| | Disclaimer: My This comment here is made out of context from
| | knowing
| | your architecture...
| | However Metacello"BaseBaseline"Configuration is a bit awkward. What
| | is
| | the requirement for the use of the first 'base' ? Can it be left
| | out
| | completely? (I guess not since that would have been the default
| | original
| | class name), or would the word 'root' provide the same semantics?
| | MetacelloRootConfiguration
| | MetacelloRootBaselineConfiguration
| |
| | cheers -ben
| |
| | > Still working my way through the scripting API ... #get and #load
| | > are basically done and today I was just going to sketch out the
| | > remaining tasks[1] before asking for volunteers to take it for a
| | > spin:)
| | >
| | > Dale
| | >
| | > [1]
| | > https://github.com/dalehenrich/metacello-work/issues?state=open
| | >
| | >
| | > ----- Original Message -----
| | > | From: "Sean P. DeNigris" < [hidden email] >
| | > | To: [hidden email]
| | > | Sent: Saturday, May 19, 2012 11:23:45 AM
| | > | Subject: [Metacello] Re: Minimal base image Metacello presence
| | > | for GemStone, Pharo, and Squeak
| | > |
| | > |
| | > | Dale Henrichs wrote
| | > | >
| | > | > I've been thinking about the best way for Metacello to have a
| | > | > "minimal
| | > | > presence" in the GemStone, Pharo and Squeak base images
| | > |
| | > | How's this coming, Dale? This would be great...
| | > |
| | > | Sean
| | > |
| | > | --
| | > | View this message in context:
| | > | http://forum.world.st/Minimal-base-image-Metacello-presence-for-GemStone-Pharo-and-Squeak-tp4334269p4630865.html
| | > | Sent from the Metacello mailing list archive at Nabble.com.
| | > |
| | >
| | >
| |
| |
|
|
|
|
| --
| Bernardo E.C.
|

vonbecmann wrote

ConfigurationOf and BaselineOf because
they are short.

+1

Or why not MetacelloConfiguration and MetacelloBaseline?