Hi Dale -

I completely understand your reasoning and I'm not criticizing it all. I 
would've done just the same to get initial adoption (and it has worked 
very well for this purpose). But now that it's being adopted I think 
it's time to take it to the next level and fix the divergence if we can.

So can I ask you to provide us with the current 'correct' current 
superclass implementation that we should use for the next set of 
experiments?

Cheers,
   - Andreas

On 5/15/2010 10:53 AM, Dale Henrichs wrote:
> Andreas,
>
> It _is_ the curse of not having a common superclass...but until Metacello is included in the base release, the curse would be getting the common superclass loaded BEFORE you can load any configurations.
>
> In the early versions of Metacello the configs were subclassed off of a common superclass, but bootstrapping was a complete pain, since you couldn't use Metacello to load itself.
>
> As it stands now, you can load any configuration into any image. If you create your configurations by copying MetacelloConfigTemplate (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) then you will get a config that has all of the "expected" methods, including #load on the class-side.
>
> To be clear...the only only reason that I don't use the common superclass model, is to make bootstrapping easy....If a MetacelloAbstractConfiguration class were included in the core image for Squeak, Pharo, and GemStone then we could migrate away from the current "self-contained" configurations.
>
> The class would be a clone of MetacelloConfigTemplate and existing configs could easily be converted to use the new superclass....
>
> The ensureMetacello logic would be included in the abstract superclass so it wouldn't be necessary to include the core implementation of Metacello in the base...
>
> I'm sure the Pharo folks would be in favor of this (as would I, speaking for GemStone)...
>
> Dale
> ----- "Andreas Raab"<andreas.raab at gmx.de>  wrote:
>
> | On 5/14/2010 6:38 PM, Chris Cunnington wrote:
> |>  ConfigurationOfExternalWebBrowser perform: #loadLatestVersion
> |>
> |>  Why?
> |>  There is no #loadLatestVersion on the class side either.
> |>
> |>  There is #lastMetacelloVersionLoad. I try:
> |>
> |>  ConfigurationOfExternalWebBrowser perform: #loadLatestVersion
> |>
> |>  Nope, that's a dud.
> |>
> |>  My summary is this: if you install a config and it has #load on the
> |>  class side, you're golden. If not, then you're in a world of the
> | unknown.
> |>  All things being equal, I'd say that Dale has created this with
> |>  something in mind where this is not a problem. Maybe it's a Pharo
> | thing.
> |>  Perhaps they have a tool that fills in the gap. But for me: no
> | #load,
> |>  means no go. And until we can get a standard API here, then it's
> | flawed.
> |>  I'm guessing that you used AppleScript on some configurations that
> | had
> |>  #load, and now you've found one that doesn't.
> |
> | It's the curse of not having a common superclass. Various variants get
> |
> | created because there's no shared standard. I think the canonical form
> |
> | is actually this:
> |
> | 	ConfigurationOfXXX project load.
> |
> | But I could be wrong; I'm no Metacello expert.
> |
> | Cheers,
> |    - Andreas
>
>