<div dir="ltr">Tobias -<div><br></div><div>Thanks for the information.</div><div><br></div><div>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.</div><div><br></div><div>John</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">John O'Keefe [|], CTO/Principal Smalltalk Architect, Instantiations Inc.<br>Skype: john_okeefe2 Mobile: +1 919 417-3181 (Business hours USA Eastern Time zone (GMT -5))<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 12:27 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,<br>
<span class=""><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>
</span>This seems correct to me.<br>
<span class=""><br>
> * On VA Smalltalk, they are always run when an Application is loaded<br>
<br>
</span>What is the semantics of "an Application is loaded"?<br>
<br>
Best<br>
-Tobias<br>
<span class=""><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>
</span>> _______________________________________________<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>
</blockquote></div><br></div>