On 17 May 2010 22:15, Dale Henrichs <dale.henrichs at gemstone.com> wrote:
> Andreas,
>
> Certainly ... GemStone has been acquired VMWare and today is my first day as a VMWare employee so things will be a little unsettled for the next day or so, but I will get something to you as soon as the decks get cleared...
>
Long live to G/S !! :)

> Dale
> ----- "Andreas Raab" <andreas.raab at gmx.de> wrote:
>
> | 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
> | >
> | >
>
>



-- 
Best regards,
Igor Stasenko AKA sig.