[Seaside-dev] on eliminating SeasidePlatformSupport

[Lukas Renggli]

>  So for Squeak (and GemStone) we should come up with a tools solution
>  that eliminates load order and initialization as a factor - I suggest
>  that we choose a variant of MoticelloConfigurations and make it a
>  requirement for Squeak and GemStone (i.e., Monticello users).

While I agree with Avi that an empty meta-package with requirements
would be a much simpler way to go, it has exactly the same drawbacks.
Monticello and MoticelloConfigurations only model hard-dependencies.
In my development images I don't have all the packages loaded, I just
use one server adapter and the Squeak platform support for the
packages I use. I load all the tests, while others don't want to
bother loading them.

>  For the sake of this discussion, I'll imagine that we have three
>  packages that compose the Seaside core implementation:
>
>     * Seaside-PLATFORM-Base
>     * Seaside-Core
>     * Seaside-PLATFORM-Core

It is not too bad as it might look like. I have updated the dependency graphs:

    http://www.lukas-renggli.ch/dropbox/

Use the SVG (with an SVG capable browser) to see the actual cause of
the dependencies as tooltips on the edges and nodes.

I see two problems, an old one and a new one:

- The old one is the circular relation between Seaside-Core and
Seaside-Development-Core. This is caused because WAComponent
references WAHalo from a method. Usually this should not be a problem,
and will automatically be resolved as both packages are loaded.
Eventually (with the context refactoring) this problem will disappear.

- The new one is the circular relation between Seaside-Core and
Seaside-Squeak-Core. It is caused by some bad inheritance relationship
of WAContinuation and WAResponseContinuation and WAAnswerContinuation.
This is a problem when loading code. WAResponse- and
WAAnswerContinuation are empty subclasses of WAContinuation purely
introduced to make debugging and testing simpler. I think the
advantage of keeping them is not given anymore.

>  Seaside-PLATFORM-Base should contain only platform-specific classes that
>  are going to be subclassed in Seaside-Core. Seaside-PLATFORM-Core should
>  contain platform-specific extension methods for the base classes (like
>  #toString and #snapshotCopy) and platform-specific subclasses of classes
>  implemented in Seaside-Core.

I doubt that this is necessary anymore after my suggested refactoring.

>  I imagine that it will be impossible to eliminate SeasidePlatformSupport
>  completely, but it's use should be restricted to methods that supply
>  platform-specific class names and not much more.

I don't think anything is wrong with SeasidePlatformSupport. The
problem is that people are tempted to add a lot of stuff in there
without thinking. Extensively using class extensions is no solution
either, because this is bound to end up with conflicts in one or the
other Smalltalk platform
(http://gbracha.blogspot.com/2008/03/monkey-patching.html). Also it
makes it harder to port, as different classes have to be kept under
observation.

>  During experiment with adding platform-specific extension methods to
>  Seaside-Core classes, I saw that for GemStone, I would be inclined to
>  solve some of the portability problems differently ...

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. Moreover it makes the code easier to read, as it looks like
a normal class reference (and not like a message send to
SeasidePlatformSupport).

To give an example, WAContinuation would be a global pointing to the
Continuation implementation in Squeak. On other platforms it could
point to another class of the core system or provided by a platform
specific package. The binding would be setup in an initialize method.

I already hear people screaming that globals are bad. Yes, in some
cases, but classes are globals too, and nobody considers classes to be
bad. What I suggest is just to use an alias to a class.

Cheers,
Lukas

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