<div dir="ltr">Tobias -<div><br></div><div>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.</div><div><br></div><div>John</div><div class="gmail_extra"><div><div class="gmail_signature"><br><a href="mailto:john_okeefe@instantiations.com" target="_blank">john_okeefe@instantiations.com</a><br><a href="http://www.instantiations.com/" target="_blank">http://www.instantiations.com</a><br><em><strong>VA Smalltalk...Onward and Upward!</strong></em></div></div>
<br><div class="gmail_quote">On Tue, Jan 27, 2015 at 4:38 PM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi John<br>
<span class=""><br>
On 27.01.2015, at 22:06, John O'Keefe <<a href="mailto:wembley@instantiations.com">wembley@instantiations.com</a>> wrote:<br>
<br>
> Tobias -<br>
><br>
> Thanks for the information.<br>
><br>
> 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.<br>
><br>
<br>
</span>Ok, thanks for clarification.<br>
To my knowledge, yes, a class initializer is only triggered upon change of it<br>
or its first installment. What you can do, however, is to use a<br>
preamble or postscript<br>
for Monticello (based on PackageInfo scripts) which is executed when a package is loaded.<br>
I would abstain from using this for application specific state.<br>
<br>
Also the guard code you saw is the way I would probably guard that application<br>
initialization is done only once…<br>
<br>
Best<br>
<span class="HOEnZb"><font color="#888888"> -Tobias<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> John<br>
><br>
> John O'Keefe [|], CTO/Principal Smalltalk Architect, Instantiations Inc.<br>
> Skype: john_okeefe2 Mobile: <a href="tel:%2B1%20919%20417-3181" value="+19194173181">+1 919 417-3181</a> (Business hours USA Eastern Time zone (GMT -5))<br>
> <a href="mailto:john_okeefe@instantiations.com">john_okeefe@instantiations.com</a><br>
> <a href="http://www.instantiations.com" target="_blank">http://www.instantiations.com</a><br>
> VA Smalltalk...Onward and Upward!<br>
><br>
> On Tue, Jan 27, 2015 at 12:27 PM, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
> Hi,<br>
><br>
> On 27.01.2015, at 18:13, John O'Keefe <<a href="mailto:wembley@instantiations.com">wembley@instantiations.com</a>> wrote:<br>
><br>
> > 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.<br>
> > * 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)<br>
><br>
> This seems correct to me.<br>
><br>
> > * On VA Smalltalk, they are always run when an Application is loaded<br>
><br>
> What is the semantics of "an Application is loaded"?<br>
><br>
> Best<br>
> -Tobias<br>
><br>
> ><br>
> > 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.<br>
> ><br>
> > I also see this sort of code in several methods called from #initialize:<br>
> ><br>
> > configureApplicationDefaults<br>
> > (configuredApplicationDefaults ifNil: [ false ]) ifFalse: [<br>
> > WAAdmin applicationDefaults<br>
> > at: #responseGenerator put: WAHtmlResponseGenerator.<br>
> > configuredApplicationDefaults := true ]<br>
> ><br>
> > This seems to be a guard against the VA Smalltalk style of class initialization.<br>
> ><br>
> > Can someone with a deeper understanding of the workings of Pharo than I have confirm that this is what is happening?<br>
> ><br>
> > Thanks, John<br>
> ><br>
> > <a href="mailto:john_okeefe@instantiations.com">john_okeefe@instantiations.com</a><br>
> > <a href="http://www.instantiations.com" target="_blank">http://www.instantiations.com</a><br>
> > _______________________________________________<br>
> > seaside-dev mailing list<br>
> > <a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
> > <a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>