[Seaside-dev] question on value of startup and shutdown lists being required

[Dale Henrichs]

Dale Henrichs wrote:
> You know, if we use a platform-specific extensions package, we can 
> eliminate SeasidePlatformSupport - I don't know if that would be a 
> good or bad thing. It is convenient to manage things in one spot, but 
> given a  thorough test suite (which is already in place for most if 
> not all of the base class extensions) it isn't necessary....95% of the 
> references to SeasidePlatformSupprt messages are from a single method 
> or a single class.
>
> If we do eliminate SeasidePlatformSupport, then the platform Core 
> package (except for Continuations) can be loaded after Seaside Core.
>
> What do you think?
>
> Dale
I went ahead and took a first cut at eliminating SeasidePlatformSupport 
and committed the following packages:

    * Seaside-Core-dkh.82
    * Seaside-Squeak-Continuation-dkh.1
    * Seaside-Squeak-Core-dkh.34
    * Seaside-Tests-dkh.70

After the sweep, there are 18 methods remaining in WASqueakPlatform:

    * 12 have no senders (ignoring tests) and I assume that they are
      used in the Development packages or not at all
    * 3 involve file system access and it is probably worth building a
      'standard' file system support class for Seaside to encapsulate
      the remaining methods plus some of the others.
    * That leaves 3 methods that need 'special attention', because they
      are sent from more than one spot (compiler access for
      WAFileLibrary and WAFileSystem), stackDepth for WAFlowTest (so it
      can't go into a core platform package), and semaphoreClass used by
      three different classes

After going through this excercise, I'm convinced that 
SeasidePlatformSupport can easily be completely eliminated.

Also by removing SeasidePlatformSupport, I can see that WAFileLibrary 
(and friends) and WAFileSystem would probably benefit from having a 
focussed platform-specific implementation rather than being somewhat 
cobbled together (in no way am I demeaning the effort that's gone into 
these classes, but referring to the somewhat crippling  constraint of 
using SeasidePlatformSupport for portability). For example, the 
#beMutable trickery does nothing for GemStone (method temps are not 
saved), so we always end up converting the byteArray, but I digress.

Anyway, I'm interested in feedback ...

Dale