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

[John O'Keefe]

Tobias -

Thanks for the clarification. I just wanted to be sure I understood what
Pharo was doing before I wrote a Seaside defect on this subject.

John

john_okeefe at instantiations.com
http://www.instantiations.com
*VA Smalltalk...Onward and Upward!*

On Tue, Jan 27, 2015 at 4:38 PM, Tobias Pape <Das.Linux at gmx.de> wrote:

> Hi John
>
> On 27.01.2015, at 22:06, John O'Keefe <wembley at instantiations.com> wrote:
>
> > Tobias -
> >
> > Thanks for the information.
> >
> > A VA Smalltalk Application is equivalent to a Monticello Package. A VA
> Smalltalk ConfigurationMap is approximately equivalent to a Metacello
> Configuration. So loading a VA Smalltalk Application is the same as loading
> a Monticello Package.
> >
>
> Ok, thanks for clarification.
> To my knowledge, yes, a class initializer is only triggered upon change of
> it
> or its first installment. What you can do, however, is to use a
>         preamble or postscript
> for Monticello (based on PackageInfo scripts) which is executed when a
> package is loaded.
> I would abstain from using this for application specific state.
>
> Also the guard code you saw is the way I would probably guard that
> application
> initialization is done only once…
>
> Best
>         -Tobias
>
>
> > John
> >
> > John O'Keefe [|], CTO/Principal Smalltalk Architect, Instantiations Inc.
> > Skype: john_okeefe2     Mobile:  +1 919 417-3181 (Business hours USA
> Eastern Time zone (GMT -5))
> > john_okeefe at instantiations.com
> > http://www.instantiations.com
> > VA Smalltalk...Onward and Upward!
> >
> > On Tue, Jan 27, 2015 at 12:27 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> > Hi,
> >
> > On 27.01.2015, at 18:13, John O'Keefe <wembley at instantiations.com>
> wrote:
> >
> > > 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)
> >
> > This seems correct to me.
> >
> > >  * On VA Smalltalk, they are always run when an Application is loaded
> >
> > What is the semantics of "an Application is loaded"?
> >
> > Best
> >         -Tobias
> >
> > >
> > > 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
> > > _______________________________________________
> > > seaside-dev mailing list
> > > seaside-dev at lists.squeakfoundation.org
> > > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20150127/6b62680e/attachment.htm