[Seaside-dev] Seaside's use of class-side #initialize

[John O'Keefe]

I'm trying to work through an anomaly in our VA Smalltalk Seaside
implementation and it seems to boil down to a difference between Pharo and
VA Smalltalk in when the class-side #initialize methods are run.
 * On Pharo, they are only run if the source for the #initialize method
that is being loaded does not match the source of the #initialize method
that was previously loaded (which is, of course, nil if the method does not
already exist in the image)
 * On VA Smalltalk, they are always run when an Application is loaded

Pharo's approach seems designed for #initialize methods with simple setter
methods (like classVarA := 7). However, since the 'source code matching'
doesn't recursively match the source code of methods being called from
#initialize, nor is there any guarantee that called methods will always
return the same thing even if their source hasn't changed, this seems like
a flawed optimization to me (at least when complex #initialize methods are
involved). But since it is what Pharo provides, I guess it is what you use.

I also see this sort of code in several methods called from #initialize:

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

This *seems* to be a guard against the VA Smalltalk style of class
initialization.

Can someone with a deeper understanding of the workings of Pharo than I
have confirm that this is what is happening?

Thanks, John

john_okeefe at instantiations.com
http://www.instantiations.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20150127/60f73dad/attachment.htm