Vassili Bykov's blog at cincom

http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?entry=3310034894




On Fri, Aug 17, 2012 at 2:32 PM, St�phane Ducasse <stephane.ducasse@inria.fr> 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
>





--
Bernardo E.C.