pharo-spec
To add to FAQ (I could not find it)
What is the difference between? ^self instantiate: (MyObject new)
and ^MyObject new
I'm using both all over the place and trying to track down a performance anomaly, so I'd like to be consistent (and safe 🙂 ). Obviously I'm inside an SpPresenter for instantiate: to be applicable. Esteban Lorenzano — 08/02/2022 nope 😛 Esteban Lorenzano — 08/02/2022 self instantiate: MyPresenter. will set the owner, forming a correct "DOM" MyPresenter new. will not set the owner, hence the formed tree DOM will be incorrect, and while there is a chance there will not be visual difference, it will lead to the usage of a different application internally, which may cause leaks, resource access problems, etc. you should not use MyPresenter new
Excellent feedback, thank you. What if I'm trying to do: MyPresenter newApplication: anApp model: aModel
Can I use self instantiate: like this?: self instantiate: (MyPresenter newApplication: anApp model: aModel)
I might be missing something from your examples above? Esteban Lorenzano — 08/02/2022 no myPresenter := self instantiate: MyPresenterClass on: aModel is correct. myPresenter := MyPresenterClass new owner: self; yourself. is also correct myPresenter := MyPresenterClass newApplication: anApplication model: aModel. is also correct, but you need it JUST for root presenters (the ones you will open) like myPresenter MyPresenterClass newApplication: anApplication model: aModel. myPresenter open.
I'm a bit confused... my 'wrapping plex' that I call from my application I can use: myWrapPres := MyPresenterClass newApplication: anApp model: aModel
understood. When I create presenters inside myWrapPres, you're suggesting then I don't use the 'newApplication' construct, but use instantiate: on: ? I'm wondering how all the 'sub'presenters have access to the application? Perhaps a nested self owner application
that eventually punches through to myWrapPres to get the application? The instantiate: is solving the issue I had where sometimes owner was nil... so I extended the newApplication: model: method to receive the 'owner' presenter so it was always available... so now I can remove all that code throughout 🙂 whalehead — 08/02/2022 I'm applying the above suggestions... so far so good. self owner application appears to work (I was worried that I might need access to application before owner was assigned... looks like the assignment order is good). Thanks! Esteban Lorenzano — 08/02/2022 is like constructing a tree you say "I will do a window with a list and a text" the window you open, is within an application but the list and text are part of the window so you have something like: Application - Window - List - Text if you look how they are implemented: newApplication: just sets the application instantiate: just sets the owner then, if you ask for presenter application then you will see presenter ask for application, if nil it asks for owner application to traverse the tree whalehead — 08/02/2022 yes, I was literally just looking at that in SpPresenter 🙂 I was doing all of that manually for my needs, (new instVars and messages), but the 'internals' that were relying on 'owner' to be set properly were catch-as-catch-can. This will at least help me be more consistent, and hopefully, resolve my performance and memory leak issues. Thanks for the tips @Esteban Lorenzano Esteban Lorenzano — 08/02/2022 note that for the widget presenters, what is mandatory is to have an owner set. You can skip the usage of instantiate: and instantiate:on: (for example to pass it along when created outside the "regular" circuit), but eventually, you need to set it before include it in a layout.
