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
The text was updated successfully, but these errors were encountered:
Original issue reported on code.google.com by
wemb...@instantiations.com
on 9 Feb 2015 at 10:34The text was updated successfully, but these errors were encountered: