[Seaside-dev] on eliminating SeasidePlatformSupport

[Dale Henrichs]

Lukas Renggli wrote:

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

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

>  
>
>> 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.
>
>  
>
Another new one may come from the technique we use to resolve the 
WAExternalID problem. A platform-specific superclass or subclass would 
introduce another 'dependency'. I think it would be overkill to expect 
the whole class to be implemented for each platform, when the bulk of 
the implementation should be identical ...

>> 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. 
>
'Easier to load' shouldn't be a factor:)

>Moreover it makes the code easier to read, as it looks like
>a normal class reference (and not like a message send to
>SeasidePlatformSupport).
>  
>
I would prefer that a normal class reference be used as well, but 
sometimes it makes sense to make the actual class configurable (using a 
message send to get the class to use) - whether you are writing a class 
to be platform independent or writing a class to be reusable for other 
purposes. Given a choice between, monkey-patching a class reference 
method, using SeasidePlatformSupport to supply a class and using a 
global wrapper for the class, I would choose the SeasidePlatformSupport 
style - but that is obviously a question of style rather than of 
functionality. As they say, 'there's more than one way to skin a cat.'

>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.
>  
>
For the specific case of having a class that is to be supplied by the 
platform the choice of using a global or a class by that name is purely 
a platform specific choice, since the platform independent code would be 
identical in either case ...

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

Dale