[Seaside-dev] on eliminating SeasidePlatformSupport

[Lukas Renggli]

> I thought that with MonticelloConfigurations you could 'open' a
>  configuration, 'update' the versions to the latest from the repository
>  (with a couple of different 'update' options) and then 'load' the
>  packages. In the version of MonticelloConfigurations in my development
>  image, the MCPackageLoader is _not_ used - if it were, then load order
>  would not be an issue.

The problem is that these are hard dependencies.

> I understood that with MonticelloConfigurations, you can have your own
>  private configuration with the list of packages you wanted to manage.
>  This would allow you to 'update' and 'load' the set of packages you were
>  interested in...Again, if the MCPackageLoader were used, package order
>  would not be an issue.

Of course, everybody can have its own configuration map. However, for
example when I add JavaScript-Core as a dependency to
Scriptaculous-Core, then everybody has to update his/her map and add
JavaScript-Core at the right position in the load order.

>  >For Seaside core classes I suggest to use globals, like it is
>  >currently done with SeasidePlatformSupport. This makes it much easier
>  >to load, because then we don't have any hard dependencies between
>  >packages.
>  >
>
> 'Easier to load' shouldn't be a factor:)

Agreed. In the end of the release cycle we will use Package Universes
to make loading of Seaside really simple. For now we just have to make
sure, that Seaside is loadable. Right now it isn't, because of the
cyclic dependencies. That's not about easiness.

>  I'm still inclined to postulate that Seaside-Core will need a pre/post
>  platform-specific package (i.e., Seaside-PLATFORM-Base and
>  Seaside-PLATFORM-Core) to accomodate platform-specific superclasses and
>  subclasses. I'm also inclined to believe that SeasidePlatformSupport
>  will live on, because there are certain situations where a simple
>  platform-specific is the best solution. This weekend (or so) I'll do
>  another trial run for a pre-post scenario and attempt to eliminate
>  SeasidePlatformSupport by using superclass/subclass as seems apropriate
>  and see how that looks and feels...

I don't really see why. Currently there are no dependencies that would
imply the need for a pre/post platform-specific package in Squeak. For
PLATFORM=Squeak the -Base package would just be empty. Of course there
is nothing wrong if porters decide to have a base-package that needs
to be loaded first. VisualWorks for example loads the whole Squeak
Collection and Date Hierarchy beforehand.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch