That's not how ephemerons work, and they also get finalized. Both of
you may be right...
On 12/26/11 16:49 , Levente Uzonyi wrote:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Levente,
Not meaning to be confrontational, but finalization does not happen "in" any
type of collection. It happens *to* elements that can be held in any type of weak
collection. As a result, they should all be thread safe and self-repairing.
I guess you're wrong. A weak collection is a collection which doesn't hold
strong references to its elements, so they can be garbage collected when
there are no other strong references to them.
Finalization is a service which triggers an action when an object is
garbage collected.
Some finalization techniques require the use of weak collections, but
otherwise weak collections are independent of finalization.
Levente
Bill
________________________________________
From: [email protected]
[[email protected]] on behalf of Levente Uzonyi
[[email protected]]
Sent: Monday, December 26, 2011 3:10 PM
To: [email protected]
Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote:
Stef,
I completely agree that events/announcements are cleaner and easier to
understand than changed/update. I don't really care whether or not the latter
is removed, because I never (directly) use it. Others might prefer to have it
retained??
I'm not supposed to say where<g>, but I have seen events, weak collections and
finalization done *really* well. In fairness, my working image is old and I need to
take another stab at building a recent image, but when I last reviewed them, Pharo's
weak collections were lacking features. They have to be thread safe, and they need
to clear nil entries left behind by finalization (which is why they must be thread
safe). The better we get with events (#on:send:to and friends), the more the current
weak collections will appear to be lacking.
Finalization only happens in WeakRegistries and those are thread safe. The
other weak collections are not subject to finalization, therefore they
don't have to be thread safe, that's why they aren't.
Levente
Bill
________________________________________
From: [email protected]
[[email protected]] on behalf of Stéphane Ducasse
[[email protected]]
Sent: Monday, December 26, 2011 10:56 AM
To: [email protected]
Subject: Re: [Pharo-project] Destiny of changed:/update:
using on:send: instead of changed/ is a nice way to reduce extra updates.
In Cuis juan kept only one mechanism and I like that.
In VisualWorks you have to use on:send:to: this way you can select with facet
is refreshed.
So I would like to deprecated changed.
Stef
Will changed:/update: disappear and be totally replaced by Announcements?
I ask because I'm using ListModel and noticed that it sends a generic "self
changed: #selectionIndex". I built a GUI that had two of them, and couldn't
differentiate between the updates, so I was going to enhance it a little.
--
View this message in context:
http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
.
