Usage of class-side #initialize is not portable

[GoogleCodeExporter]

The semantics of when the class-side #initialize method are not consistent 
across implementations.

In Pharo, the class-side #initialize is run on the first load of code or when 
the source of the #initialize method changes.

In VA Smalltalk, the class side #initialize is run on every load of code.

I don't know the semantics on other platforms.

This problem has apparently been discovered in the past since some Seaside 
#initialize methods contain guard code to ensure they are not rerun. For 
example, WAEnvironment class>>#initialize calls configureApplicationDefaults 
which has this (guard coded) implementation:

configureApplicationDefaults
    (configuredApplicationDefaults ifNil: [ false ]) ifFalse: [
        WAAdmin applicationDefaults
            at: #responseGenerator put: WAHtmlResponseGenerator.
        configuredApplicationDefaults := true ]

So, assuming that guard codes are the proper way to handle this situation, I 
find only one problematic class-side initialization - WASharedConfiguration 
class>>#initialize:

initialize
    instances := Set new

This needs to be changed to:

initialize
    instances ifNil: [ instances := Set new ]

Since Pharo will run the #initialize method only once, this will cause no harm 
there, and since VA Smalltalk will run the #initialize method every time the 
code is loaded, it is necessary there.

Original issue reported on code.google.com by wemb...@instantiations.com on 9 Feb 2015 at 10:34

[marschall]

Name: Seaside-Core-pmm.862
Author: pmm
Time: 17 July 2015, 10:32:50.323475 am
UUID: 82f075d2-59cd-4b21-8c18-2b2d91eac009
Ancestors: Seaside-Core-pmm.861

#838 Usage of class-side #initialize is not portable

[marschall]

Name: Seaside-Core-pmm.862
Author: pmm
Time: 17 July 2015, 10:32:50.323475 am
UUID: 82f075d2-59cd-4b21-8c18-2b2d91eac009
Ancestors: Seaside-Core-pmm.861

#838 Usage of class-side #initialize is not portable