Seaside's use of class-side #initialize

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Seaside's use of class-side #initialize

Tobias Pape
Hi,

On 27.01.2015, at 18:13, John O'Keefe <[hidden email]> 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
>
> [hidden email]
> http://www.instantiations.com
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Seaside's use of class-side #initialize

John O'Keefe
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.

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))
[hidden email]
http://www.instantiations.com
VA Smalltalk...Onward and Upward!

On Tue, Jan 27, 2015 at 12:27 PM, Tobias Pape <[hidden email]> wrote:
Hi,

On 27.01.2015, at 18:13, John O'Keefe <[hidden email]> 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
>
> [hidden email]
> http://www.instantiations.com
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev




_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Seaside's use of class-side #initialize

Tobias Pape
Hi John

On 27.01.2015, at 22:06, John O'Keefe <[hidden email]> 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))
> [hidden email]
> http://www.instantiations.com
> VA Smalltalk...Onward and Upward!
>
> On Tue, Jan 27, 2015 at 12:27 PM, Tobias Pape <[hidden email]> wrote:
> Hi,
>
> On 27.01.2015, at 18:13, John O'Keefe <[hidden email]> 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
> >
> > [hidden email]
> > http://www.instantiations.com
> > _______________________________________________
> > seaside-dev mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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

[hidden email]
http://www.instantiations.com
VA Smalltalk...Onward and Upward!

On Tue, Jan 27, 2015 at 4:38 PM, Tobias Pape <[hidden email]> wrote:
Hi John

On 27.01.2015, at 22:06, John O'Keefe <[hidden email]> 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:  <a href="tel:%2B1%20919%20417-3181" value="+19194173181">+1 919 417-3181 (Business hours USA Eastern Time zone (GMT -5))
> [hidden email]
> http://www.instantiations.com
> VA Smalltalk...Onward and Upward!
>
> On Tue, Jan 27, 2015 at 12:27 PM, Tobias Pape <[hidden email]> wrote:
> Hi,
>
> On 27.01.2015, at 18:13, John O'Keefe <[hidden email]> 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
> >
> > [hidden email]
> > http://www.instantiations.com
> > _______________________________________________
> > seaside-dev mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev




_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev