best practices for model/view dependencies
Locked
best practices for model/view dependencies
 
|
I'm still relatively new to Pharo and to Smalltalk in general, and
I've hit a situation where I'd like a model that notifies dependent views when it changes. Classically, it looks like this was done through #addDependent:, #update, #changed, #release and friends. I don't need more than a symbol message and an associated object, so I could live with that API, but I don't quite understand #release. It sounds like originally Object class held (non-weak) references to all objects that had dependents, so unless the dependents were explicitly released, the objects would never be released. I get the impression that at some point this was switched to using weak references, so I wouldn't have to worry about closed parent/dependent loops, but I can't find this explicitly spelled out anywhere. - Question 1: Does the basic addDependent/etc. system on Pharo use weak references? - Question 2: Am I correct in understanding that the main point of the Model class was to avoid having an entry in the Object class variable, so a closed parent/dependent loop could be garbage collected? - Question 3: If Pharo uses weak references, is there any point to the Model class? I've also seen some references to the Announcements framework, but I can't find as much documentation on it as I can on the "basic" Smalltalk dependency mechanism. It seems a bit more complex, with actual event classes, but I've not understood it yet. - Question 4: Should I prefer using Announcements for even mostly trivial cases? - Question 5: What benefits would Announcements give me? Any overall pointers would be appreciated as well. Thanks, Johann |
Re: best practices for model/view dependencies
|
|
On Aug 17, 2012, at 3:46 PM, Johann Hibschman wrote: > I'm still relatively new to Pharo and to Smalltalk in general, welcome :) > and > I've hit a situation where I'd like a model that notifies dependent > views when it changes. > > Classically, it looks like this was done through #addDependent:, > #update, #changed, #release and friends. I don't need more than a > symbol message and an associated object, so I could live with that > API, but I don't quite understand #release. Do not use changed:/update because - it broadcasts to all the dependents - you have to build case statement in the update > It sounds like originally > Object class held (non-weak) references to all objects that had > dependents, so unless the dependents were explicitly released, the > objects would never be released. I get the impression that at some > point this was switched to using weak references, so I wouldn't have > to worry about closed parent/dependent loops, but I can't find this > explicitly spelled out anywhere. > > - Question 1: Does the basic addDependent/etc. system on Pharo use > weak references? You can use on:send:to: on Morph or when: anEventSelector send: aMessaageSelector to: anObject on object You can also use Announcement. > - Question 2: Am I correct in understanding that the main point of the > Model class was to avoid having an entry in the Object class variable, > so a closed parent/dependent loop could be garbage collected? This table in the Object is an old idea and we should remove it. People should use ValueHolder > - Question 3: If Pharo uses weak references, is there any point to the > Model class? > > I've also seen some references to the Announcements framework, but I > can't find as much documentation on it as I can on the "basic" > Smalltalk dependency mechanism. It seems a bit more complex, with > actual event classes, but I've not understood it yet. In fact you get an object and not only a symbol so you can pass more logic > - Question 4: Should I prefer using Announcements for even mostly trivial cases? when: anEventSelector send: aMessaageSelector to: anObject which is should unify with the on:send:to: of Morph > - Question 5: What benefits would Announcements give me? that you can pass a complex object around. Read the blog of Vassili on Announcement. > > Any overall pointers would be appreciated as well. > > Thanks, > Johann > |
Re: best practices for model/view dependencies
|
|
Vassili Bykov's blog at cincom On Fri, Aug 17, 2012 at 2:32 PM, Stéphane Ducasse <[hidden email]> wrote:
Bernardo E.C. |
Re: best practices for model/view dependencies
|
|
In reply to this post by Stéphane Ducasse
Thanks, that (along with the other comments here) was enough to get me
started. I managed to get a basic proof-of-concept up and running. Oddly enough, I hadn't thought to check the Help browser until I saw the Announcements-Help package. Once I read it, I found it very helpful, so if anyone else comes looking for pointers, that's a good place to direct them. Regards, Johann On Fri, Aug 17, 2012 at 1:32 PM, Stéphane Ducasse <[hidden email]> wrote: > > On Aug 17, 2012, at 3:46 PM, Johann Hibschman wrote: > >> I'm still relatively new to Pharo and to Smalltalk in general, > > welcome :) > >> and >> I've hit a situation where I'd like a model that notifies dependent >> views when it changes. >> >> Classically, it looks like this was done through #addDependent:, >> #update, #changed, #release and friends. I don't need more than a >> symbol message and an associated object, so I could live with that >> API, but I don't quite understand #release. > > Do not use changed:/update because > - it broadcasts to all the dependents > - you have to build case statement in the update > >> It sounds like originally >> Object class held (non-weak) references to all objects that had >> dependents, so unless the dependents were explicitly released, the >> objects would never be released. I get the impression that at some >> point this was switched to using weak references, so I wouldn't have >> to worry about closed parent/dependent loops, but I can't find this >> explicitly spelled out anywhere. >> >> - Question 1: Does the basic addDependent/etc. system on Pharo use >> weak references? > > You can use on:send:to: on Morph or when: anEventSelector send: aMessaageSelector to: anObject on object > You can also use Announcement. > >> - Question 2: Am I correct in understanding that the main point of the >> Model class was to avoid having an entry in the Object class variable, >> so a closed parent/dependent loop could be garbage collected? > > This table in the Object is an old idea and we should remove it. > People should use ValueHolder > >> - Question 3: If Pharo uses weak references, is there any point to the >> Model class? >> >> I've also seen some references to the Announcements framework, but I >> can't find as much documentation on it as I can on the "basic" >> Smalltalk dependency mechanism. It seems a bit more complex, with >> actual event classes, but I've not understood it yet. > > In fact you get an object and not only a symbol so you can pass more logic > >> - Question 4: Should I prefer using Announcements for even mostly trivial cases? > when: anEventSelector > send: aMessaageSelector > to: anObject > > which is should unify with the on:send:to: of Morph > >> - Question 5: What benefits would Announcements give me? > > that you can pass a complex object around. > Read the blog of Vassili on Announcement. > >> >> Any overall pointers would be appreciated as well. >> >> Thanks, >> Johann >> > > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |