[Seaside-dev] on eliminating SeasidePlatformSupport

[Dale Henrichs]

Here's another take on addressing the problems represented by 
SeasidePlatformSupport .  This time I'm not trying to address a specific 
issue so I'll be more general...

First off, I don't think that code load order or initialization issues 
should dictate architetural decisions. Load order and initialization are 
tools issues and  can be solved as such.

Monticello is perfectly capabable of composing the definitions from 
multiple packages that are then loaded and initialized correctly - 
reqiredPackages does this already and if there isn't a variant of 
MonticelloConfigurations out there that uses MCPackageLoader there 
should be! For the folks that are not using Monticello, they are in a 
position where they need to 'manufacture' an initialization step anyway, 
so I would think  that  getting the Seaside classes initialized 
correctly is a problem that has already been solved.

Load order for classes is a still a problem, so we need to partition the 
Seaside packages into pre-core/post-core.

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).

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

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.

We should completely avoid platform-specific extension methods for 
classes defined in Seaside-Core and we should avoid (as much as 
possible) defining methods in SeasidePlatformSupport. If there is a 
platform-specific component to a class, we should come up with 
class-based solutions to each problem rather than use platform-specific 
extension methods for platform specific code.

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.

Supplying platform-specific methods in SeasidePlatformSupport was a good 
solution for Seaside2.8 - it was real easy to see and manage the 
platform speicific code. The down-side of using SeasidePlatformSupport 
for platform-specific _methods_ is that it doesn't make it possible to 
provide platform-specific _algorithms_. Implementors are constrained by 
the set of platform-specific methods available and porters are 
constrained to supplying platform-specific implementaions of methods 
rather than platform-specific _solutions_.

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 ...

WAFileLibrary is a case in point. For the GemStone port, I dutifully 
supplied the method #beMutable, since it is sent in Seaside. GemStone 
will not change the persistent state of a method temp during execution, 
because that would result in commit conflicts, so for GemStone the whole 
WAFileLibrary implementation is sub-optimal. I'm not trying to pick on 
WAFileLibrary, but I think that if WAFileLbrary were pluggable we 
wouldn't need the half a dozen methods in SeasidePlatformSupport and 
each of the platforms would have the option of implementing a 
platform-specific solution.

WAExternalID is an example where a platform-specific superclass is 
probably the best solution.

This didn't show up in SeasidePlatformSupport (yet), but doing 
#allInstances isn't a big deal in conventional smalltalks. In a large 
GemStone database you really don't want to do #allInstances very often 
and if you do, you have to do an abort, which is not something done 
lightly ... There are a handful of places in the core where allInstances 
is used and the correct solution is to provide a platform-specific 
algorithm for doing the work, rather than supplying an platform-specific 
implementation of allInstances. Platforms that can use #allInstances, 
shouldn't be penalized by platforms where #allInstances can't going to 
be used - the non-allInstances involves more than just one method.

There will be other cases I'm sure....

Comments?

Dale