[Pharo-project] A thought about Morphic and Seaside
Hello guys We were browsing code with marcus and I realized something quite funny about Morphic. Morphic is somehow close to seaside for the following point: There is a list that contains the children. In Seaside you have to return a list containing the children components too. Now this is really interesting to see that a lot of complexity in Morphic code comes from the fact that the programmers avoided to have an instance variable for an element to the pretext that the element was already in the submorphs list. Then you end up with code like label: aString | oldLabel m | (oldLabel := self findA: StringMorph) ifNotNil: [oldLabel delete]. m := StringMorph contents: aString font: TextStyle defaultFont. self extent: m extent + (borderWidth + 6). m position: self center - (m extent // 2). self addMorph: m. m lock label | s | s := ''. self allMorphsDo: [:m | (m isKindOf: StringMorph) ifTrue: [s := m contents]]. ^ s instead of label ^ label label: aString .... where you have to query the submorph of the right kind.... Marcus was mentioning to me that Morphic is a bit like applying GraphTraversal that the law of demeter guy loves so much. And we see the results, an ugly code all over the places. So I will certainly play a bit with this design difference to see what it makes. But I'm sure now it makes a big difference. stef
A side related question. I wonder, when you have more instance variable referencing the same object, does it make more difficult to get unused object garbage collected? In DrGeo I *fell* I have this kind of problem with object referenced in other object and vis-versa, then never garbage collected. Or did I miss something? Hilaire 2008/8/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hello guys
We were browsing code with marcus and I realized something quite funny about Morphic. Morphic is somehow close to seaside for the following point:
There is a list that contains the children. In Seaside you have to return a list containing the children components too. Now this is really interesting to see that a lot of complexity in Morphic code comes from the fact that the programmers avoided to have an instance variable for an element to the pretext that the element was already in the submorphs list.
Then you end up with code like
label: aString
| oldLabel m | (oldLabel := self findA: StringMorph) ifNotNil: [oldLabel delete]. m := StringMorph contents: aString font: TextStyle defaultFont. self extent: m extent + (borderWidth + 6). m position: self center - (m extent // 2). self addMorph: m. m lock
label | s | s := ''. self allMorphsDo: [:m | (m isKindOf: StringMorph) ifTrue: [s := m contents]]. ^ s
instead of
label ^ label
label: aString
....
where you have to query the submorph of the right kind....
Marcus was mentioning to me that Morphic is a bit like applying GraphTraversal that the law of demeter guy loves so much. And we see the results, an ugly code all over the places.
So I will certainly play a bit with this design difference to see what it makes. But I'm sure now it makes a big difference.
stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Aug 18, 2008 at 9:13 AM, Hilaire Fernandes <hilaire@ofset.org> wrote:
A side related question. I wonder, when you have more instance variable referencing the same object, does it make more difficult to get unused object garbage collected? In DrGeo I *fell* I have this kind of problem with object referenced in other object and vis-versa, then never garbage collected. Or did I miss something?
I'm unsure it answers your question but the garbage collector should be able to detect cycles of unused objects and delete them. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
Yes damien is right. Stef
A side related question. I wonder, when you have more instance variable referencing the same object, does it make more difficult to get unused object garbage collected? In DrGeo I *fell* I have this kind of problem with object referenced in other object and vis-versa, then never garbage collected. Or did I miss something?
I'm unsure it answers your question but the garbage collector should be able to detect cycles of unused objects and delete them.
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What is cycle of unused objects? Circular references of unused objects? What I did, for the Drgeo canvas, when the user ask to dismiss it, I am releasing and forcing to nil the instance variables. But it brings other problems. I ma curious to know how developers handle this problem. Sorry I am a bit off-topic. Hilaire 2008/8/18 Damien Cassou <damien.cassou@gmail.com>:
On Mon, Aug 18, 2008 at 9:13 AM, Hilaire Fernandes <hilaire@ofset.org> wrote:
A side related question. I wonder, when you have more instance variable referencing the same object, does it make more difficult to get unused object garbage collected? In DrGeo I *fell* I have this kind of problem with object referenced in other object and vis-versa, then never garbage collected. Or did I miss something?
I'm unsure it answers your question but the garbage collector should be able to detect cycles of unused objects and delete them.
-- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hilaire Fernandes wrote:
What is cycle of unused objects? Circular references of unused objects?
What I did, for the Drgeo canvas, when the user ask to dismiss it, I am releasing and forcing to nil the instance variables. But it brings other problems. I ma curious to know how developers handle this problem.
You normally don't need to nil out the variables unless you want to make sure that an object is easily recognized as invalid (e.g. you check for nil values elsewhere). When objects don't get garbage collected they often are registered somewhere as dependents, in caches or similar places. Michael
2008/8/18 Michael Rueger <m.rueger@acm.org>:
Hilaire Fernandes wrote:
What is cycle of unused objects? Circular references of unused objects?
What I did, for the Drgeo canvas, when the user ask to dismiss it, I am releasing and forcing to nil the instance variables. But it brings other problems. I ma curious to know how developers handle this problem.
You normally don't need to nil out the variables unless you want to make sure that an object is easily recognized as invalid (e.g. you check for nil values elsewhere).
When objects don't get garbage collected they often are registered somewhere as dependents, in caches or similar places.
This is exactly what I thought at first, but I still see some instances lying in my image, I am indeed using dependents but I take care of releasing it. Hilaire
On Aug 18, 2008, at 11:58 AM, Hilaire Fernandes wrote:
What is cycle of unused objects? Circular references of unused objects?
What I did, for the Drgeo canvas, when the user ask to dismiss it, I am releasing and forcing to nil the instance variables. But it brings other problems. I ma curious to know how developers handle this problem. Sorry I am a bit off-topic.
No this is not. You should try to chase your pointers to the objects that you suspect not to be gced (pointerfinder should help for that). Stef
Stéphane Ducasse wrote:
No this is not. You should try to chase your pointers to the objects that you suspect not to be gced (pointerfinder should help for that).
in my experience there are a few (or maybe just one) location(s) that pointerfinder doesn't find. We had the occasional problems that we just couldn't find were an object is hold on to. Suspect were terminated processes and theirs stack, blocks or similar, but as I said, we couldn't figure it out occasionally. It's been a long standing problem with Smalltalk though, I remember having that problem way back with ObjectWorks. Michael
On Mon, Aug 18, 2008 at 11:58 AM, Hilaire Fernandes <hilaire@ofset.org> wrote:
What is cycle of unused objects? Circular references of unused objects?
Exactly. It's when you have two objects A and B, each referring to the other and no other object in memory pointing to one of them. Old GCs had problem with that because they used reference counters. In this case, the counters equals to one in both objects whereas the GC collects only objects with a zero-count. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
participants (4)
-
Damien Cassou -
Hilaire Fernandes -
Michael Rueger -
Stéphane Ducasse