I don't know how to parse "weak set nilling is totally unrelated to
finalization", maybe we're talking about different things when we use
the term "finalization", I don't know.
On 12/27/11 10:59 , Schwab,Wilhelm K wrote:
Is it unrelated by chance/evolution or because that is the correct thing to do?
Dolphin does not scope finalization, and the purity of the design is tangible.
As I have said, Dolphin began with structured exceptions, hindsight regarding
multi-processing, and finalization all in clear view, and these features work
together as a result.
Squeak (and hence Pharo), by its roots in Smalltalk-80 has a bit more baggage
and some associated rough spots.
________________________________________
From: [email protected]
[[email protected]] on behalf of Levente Uzonyi
[[email protected]]
Sent: Tuesday, December 27, 2011 9:33 AM
To: [email protected]
Subject: Re: [Pharo-project] Destiny of changed:/update:
(quote fixed by hand)
On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote:
I did indeed write that weak collections must be thread safe and
self-repairing, which is quite correct.
It has everything to do with finalization, which can be applied to any object
(e.g. the handle body pattern).
What good are weak collections if they either prevent garbage collection of
their elements (are hence not weak) or can't cope with the finalization of
objects that are removed by the garbage collection that they (correctly) did
not prevent (incomplete implementation)?
Weak collections are used outside of the scope of finalization, otherwise
most of them wouldn't exist. For example Symbols are stored in WeakSets, so when
a symbol is not used anymore, itcan be garbage collected. And this is
_totally_ unrelated to finalization.
Levente
Bill
________________________________________
From: [email protected]
[[email protected]] on behalf of Levente Uzonyi
[[email protected]]
Sent: Monday, December 26, 2011 9:06 PM
To: [email protected]; [email protected]
Subject: Re: [Pharo-project] Destiny of changed:/update:
On Mon, 26 Dec 2011, Andres Valloud wrote:
That's not how ephemerons work, and they also get finalized. Both of you may
be right...
Well, yes, with ephemerons you can implement a finalization mechanism
which is triggered when the object is _about to be_ garbage collected
(note that the finalize() method in java is similar). But it doesn't mean
that finalization has anything to do with weak collections or that weak
collections should be thread safe, which is what Bill wrote.
Levente
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.
.
.
