20 Mar
2003
20 Mar
'03
12:14 p.m.
[For Lukas and Steph] Last time with Gabriela we have coded together the Page visited
component. We get stuck because we put a method such as:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Page>>accept: aVisitor
aVisitor acceptPage: self.
(self template propertyAt: #visitedPages) addPage: self
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The result was the component reference all the pages of the wiki, even if we display it or
not.
I understood why. A page is not only visited by a rendered visitor, by also by
VisitorReferences.
So, a code something like works:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Page>>accept: aVisitor
aVisitor acceptPage: self.
(aVisitor isKindOf: VisitorRenderer) ifTrue: [
(self template propertyAt: #visitedPages) addPage: self]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Okay, now I have some questions:
1- What is the meaning of VisitorReferences,
2- What is the meaning of TemplateReferences
The both question are nearly the same, but I do not have so much time to dive in the
code.
My guess is it is needed for the saving mechanism...
and the last one:
3- A page should get a reference so the component for being referenced when visited. In
the previous code "self template" return the __root__ of the template structure.
So, our first idea was to add a property in the root for referencing the component. But,
we need to modify such method. And I admit it is not homogenous :-)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
defaultTemplate
| ans v |
ans := TemplateRoot
child: (TemplateContainerRows new
add: (TemplateStringTitleWiki new);
add: (TemplateContainerColumns new
add: (TemplateStructuresPath new);
add: (TemplateHeatBox new);
yourself);
add: (TemplateContainerColumns new
add: (TemplateContainerRows new
add: (TemplateActionsCustom new);
add: (TemplateStructuresReferences new);
add: (v := TemplateVisitedPages new);
yourself);
add: (TemplateContainerRows new
add: (TemplateStringTitleAction new);
add: (TemplateStringContent new);
yourself);
yourself);
add: (TemplateStringAbout new);
yourself).
ans propertyAt: #visitedPages put: v. "<=======Here a new line !!!!"
^ ans
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lukas, tell me what do you think about this way for letting a page to access a
component...
I think it is not bad...
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
20 Mar
20 Mar
1:37 p.m.
Okay sorry.
I am a kind of ashamed by this email. A real newbies mistake.
The correct way is to create a new Visitor inheriting from VisitorRenderer*
In short the responsability of adding a page in the PagesVisitedComponent belongs to the
visitor and __not__ to the page, as I first thought.
I will never make a such mistake, I promise :-)
Alexandre
On Thu, Mar 20, 2003 at 12:14:26PM +0100, Alexandre Bergel wrote:
[For Lukas and Steph] Last time with Gabriela we have
coded together the Page visited component. We get stuck because we put a method such as:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Page>>accept: aVisitor
aVisitor acceptPage: self.
(self template propertyAt: #visitedPages) addPage: self
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The result was the component reference all the pages of the wiki, even if we display it
or not.
I understood why. A page is not only visited by a rendered visitor, by also by
VisitorReferences.
So, a code something like works:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Page>>accept: aVisitor
aVisitor acceptPage: self.
(aVisitor isKindOf: VisitorRenderer) ifTrue: [
(self template propertyAt: #visitedPages) addPage: self]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Okay, now I have some questions:
1- What is the meaning of VisitorReferences,
2- What is the meaning of TemplateReferences
The both question are nearly the same, but I do not have so much time to dive in the
code.
My guess is it is needed for the saving mechanism...
and the last one:
3- A page should get a reference so the component for being referenced when visited. In
the previous code "self template" return the __root__ of the template structure.
So, our first idea was to add a property in the root for referencing the component. But,
we need to modify such method. And I admit it is not homogenous :-)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
defaultTemplate
| ans v |
ans := TemplateRoot
child: (TemplateContainerRows new
add: (TemplateStringTitleWiki new);
add: (TemplateContainerColumns new
add: (TemplateStructuresPath new);
add: (TemplateHeatBox new);
yourself);
add: (TemplateContainerColumns new
add: (TemplateContainerRows new
add: (TemplateActionsCustom new);
add: (TemplateStructuresReferences new);
add: (v := TemplateVisitedPages new);
yourself);
add: (TemplateContainerRows new
add: (TemplateStringTitleAction new);
add: (TemplateStringContent new);
yourself);
yourself);
add: (TemplateStringAbout new);
yourself).
ans propertyAt: #visitedPages put: v. "<=======Here a new line !!!!"
^ ans
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lukas, tell me what do you think about this way for letting a page to access a
component...
I think it is not bad...
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
6:11 p.m.
"Visitor
(...)
Discussion
Is this object oriented design?
At first glance, the Visitor pattern seems contrary to classic
object-oriented design.
"(...Something how you normally would do it without using the
visitor-pattern)"
However, there are a couple of downsides to this approach. First,
nobody wants
to - or does - talk about this in the object-oriented literature, but
dispersing the draw code
all over the class hierarchy is problematic from a program
understanding perspective."
Why? Don't I do that all the time?
" (...)
Second, when we distribute the responsibility and implementation of an
operation involving the graphic element classes to each class, it's
harder to add a new
operation. Doing so means adding a new method to every Geometric class.
Hence, this solution is better when the set of operations is basically
static."
(Design Patterns Smalltalk Companion)
Hey, we have class-extensions.
I remain unconvinced/undecided about the visitor-pattern, is it
another C++-Legacy?
Markus
Am Donnerstag, 20.03.03 um 13:37 Uhr schrieb Alexandre Bergel:
Okay sorry.
I am a kind of ashamed by this email. A real newbies mistake.
The correct way is to create a new Visitor inheriting from
VisitorRenderer*
In short the responsability of adding a page in the
PagesVisitedComponent belongs to the visitor and __not__ to the page,
as I first thought.
I will never make a such mistake, I promise :-)
Alexandre
On Thu, Mar 20, 2003 at 12:14:26PM +0100, Alexandre Bergel wrote:
[For Lukas and Steph] Last time with Gabriela we
have coded together
the Page visited component. We get stuck because we put a method such
as:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Page>>accept: aVisitor
aVisitor acceptPage: self.
(self template propertyAt: #visitedPages) addPage: self
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The result was the component reference all the pages of the wiki,
even if we display it or not.
I understood why. A page is not only visited by a rendered visitor,
by also by VisitorReferences.
So, a code something like works:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Page>>accept: aVisitor
aVisitor acceptPage: self.
(aVisitor isKindOf: VisitorRenderer) ifTrue: [
(self template propertyAt: #visitedPages) addPage: self]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Okay, now I have some questions:
1- What is the meaning of VisitorReferences,
2- What is the meaning of TemplateReferences
The both question are nearly the same, but I do not have so much time
to dive in the code.
My guess is it is needed for the saving mechanism...
and the last one:
3- A page should get a reference so the component for being
referenced when visited. In the previous code "self template" return
the __root__ of the template structure. So, our first idea was to add
a property in the root for referencing the component. But, we need to
modify such method. And I admit it is not homogenous :-)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
defaultTemplate
| ans v |
ans := TemplateRoot
child: (TemplateContainerRows new
add: (TemplateStringTitleWiki new);
add: (TemplateContainerColumns new
add: (TemplateStructuresPath new);
add: (TemplateHeatBox new);
yourself);
add: (TemplateContainerColumns new
add: (TemplateContainerRows new
add: (TemplateActionsCustom new);
add: (TemplateStructuresReferences new);
add: (v := TemplateVisitedPages new);
yourself);
add: (TemplateContainerRows new
add: (TemplateStringTitleAction new);
add: (TemplateStringContent new);
yourself);
yourself);
add: (TemplateStringAbout new);
yourself).
ans propertyAt: #visitedPages put: v. "<=======Here a new line
!!!!"
^ ans
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lukas, tell me what do you think about this way for letting a page to
access a component...
I think it is not bad...
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
6:21 p.m.
We can discuss hours about this, of course :-)
But one of the things is that the visitor approach is more resistant to
changes in the elements hierarchy than directly extending the elements
hierarchy with methods.
Suppose very simple hierarchy (hey, this is ascii :-) ):
A
/ \
B C
We want to have operations on these elements (say, print and display).
So we have two options:
(1) add methods print and display directly on each of these classes
(put them in a different package, of course)
(2) make visitors.
Now, suppose that in version two of the simple example I get rid of
class C. Then I cannot load the packages anymore (you will get an
unloadable method because C does not exist anymore). But your visitor
will have no problems. It will just have an obsolete method that is not
called anymore.
And then there is of course the fact that you can swap visitors at
runtime (see StarBrowser or SmallWiki), and you cannot do that without
resorting to meta-programming tricks (which is against not resistant
against change) in the non-visitor approach.
But I agree that you should think before you do :-)
On Thursday, March 20, 2003, at 06:11 PM, Markus Gälli wrote:
"Visitor
(...)
Discussion
Is this object oriented design?
At first glance, the Visitor pattern seems contrary to classic
object-oriented design.
"(...Something how you normally would do it without using the
visitor-pattern)"
However, there are a couple of downsides to this approach. First,
nobody wants
to - or does - talk about this in the object-oriented literature, but
dispersing the draw code
all over the class hierarchy is problematic from a program
understanding perspective."
Why? Don't I do that all the time?
" (...)
Second, when we distribute the responsibility and implementation of an
operation involving the graphic element classes to each class, it's
harder to add a new
operation. Doing so means adding a new method to every Geometric class.
Hence, this solution is better when the set of operations is basically
static."
(Design Patterns Smalltalk Companion)
Hey, we have class-extensions.
I remain unconvinced/undecided about the visitor-pattern, is it
another C++-Legacy?
Markus
Am Donnerstag, 20.03.03 um 13:37 Uhr schrieb Alexandre Bergel:
Roel Wuyts Software
Composition Group
roel.wuyts(a)iam.unibe.ch University of Bern,
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org
Okay sorry.
I am a kind of ashamed by this email. A real newbies mistake.
The correct way is to create a new Visitor inheriting from
VisitorRenderer*
In short the responsability of adding a page in the
PagesVisitedComponent belongs to the visitor and __not__ to the page,
as I first thought.
I will never make a such mistake, I promise :-)
Alexandre
On Thu, Mar 20, 2003 at 12:14:26PM +0100, Alexandre Bergel wrote:
[For Lukas and Steph] Last time with Gabriela we
have coded together
the Page visited component. We get stuck because we put a method
such as:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Page>>accept: aVisitor
aVisitor acceptPage: self.
(self template propertyAt: #visitedPages) addPage: self
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The result was the component reference all the pages of the wiki,
even if we display it or not.
I understood why. A page is not only visited by a rendered visitor,
by also by VisitorReferences.
So, a code something like works:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Page>>accept: aVisitor
aVisitor acceptPage: self.
(aVisitor isKindOf: VisitorRenderer) ifTrue: [
(self template propertyAt: #visitedPages) addPage: self]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Okay, now I have some questions:
1- What is the meaning of VisitorReferences,
2- What is the meaning of TemplateReferences
The both question are nearly the same, but I do not have so much
time to dive in the code.
My guess is it is needed for the saving mechanism...
and the last one:
3- A page should get a reference so the component for being
referenced when visited. In the previous code "self template" return
the __root__ of the template structure. So, our first idea was to
add a property in the root for referencing the component. But, we
need to modify such method. And I admit it is not homogenous :-)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
defaultTemplate
| ans v |
ans := TemplateRoot
child: (TemplateContainerRows new
add: (TemplateStringTitleWiki new);
add: (TemplateContainerColumns new
add: (TemplateStructuresPath new);
add: (TemplateHeatBox new);
yourself);
add: (TemplateContainerColumns new
add: (TemplateContainerRows new
add: (TemplateActionsCustom new);
add: (TemplateStructuresReferences new);
add: (v := TemplateVisitedPages new);
yourself);
add: (TemplateContainerRows new
add: (TemplateStringTitleAction new);
add: (TemplateStringContent new);
yourself);
yourself);
add: (TemplateStringAbout new);
yourself).
ans propertyAt: #visitedPages put: v. "<=======Here a new line
!!!!"
^ ans
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lukas, tell me what do you think about this way for letting a page
to access a component...
I think it is not bad...
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
7:52 p.m.
(Design Patterns Smalltalk Companion)
Definitively a must read and re read and re re read.
For the visitor Gamma said that this is not OO so this should be true.
If Good says so...
Stef
I thought that design was about tradeoffs
Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch)
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if,
by doing something different, today might not be your last day on
earth" Calvin&Hobbes
"The best way to predict the future is to invent it..." Alan Kay.
Open Source Smalltalks: www.squeak.org,
www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at www.iam.unibe.ch/~ducasse/FreeBooks.html
10:45 p.m.
(Design
Patterns Smalltalk Companion)
Definitively a must read and re read and re re read.
For the visitor Gamma said that this is not OO so this should be true.
If Good says so... 
10:53 p.m.
No, they don't say that, they just say to be carefully.
I think, it's just that if the verb is responsible for the action
and not the noun, and the "noun"-object stays stupid it might be
a bad smell...
The main question remains, if you are assigning responsibilities
in a right and balanced way.
Personally I haven't understood, why Visitors could not be seen
as Strategies (at least when you want to apply several
printing/rendering...
strategies, literally) and I am looking forward to read a paper/article
(in JOOP?)
Doru told me about, which compares Visitor with Strategy
Cheers
Markus
Am Donnerstag, 20.03.03 um 22:45 Uhr schrieb Lukas Renggli:
that double-dispatch is not OO too?
Lukas
--
21 Mar
21 Mar
9:20 a.m.
[Meta-remark: this whole discussion is about concerns, and properly
separating these concerns. For example, in your previous question on
why having a visitor, the overall reason is that there is two concerns:
one is performing an action on elements in a tree (disregarding the
actual form of the tree), another is the tree itself (whatever your
tree needs to do). If you have these two clear concerns, separate them.
This also answers your question regarding'why should I always use a
visitor'. Separation of concerns gives you an answer: if the only thing
your tree needs to do is print, then it might not be worth it (you then
have only one concern). But then let's not forget that it will be
difficult to add another action later on (like displaying). There is no
prefab all-good solution.
For example, in the case of the StarBrowser and SmallWiki we use a
visitor because we use the possibility to switch visitors all the time.
The Classifications tree has only the behaviour to do traversals and
maintain parent links etc. In the case of Soul, for example, it is more
interesting because you see the roles in practice. The problem is that
your parse tree sometimes needs to do different things, but you have to
decompose it along one direction. In Soul, we decided that it was the
main responsibility to implement the unification protocol directly on
the parse tree: unification is stable (it does not change much, apart
from possible bugfixes), and we need it a lot so it should be fast. So
the Soul parse tree implements the unification on the tree, because it
is logically what the tree needs to do (what we decided that it should
do). However, then we have some other operations that we want to do
with this tree, like pretty printing. For these things we used a
visitor. ]
What you factor out with the visitor is the traversal behaviour. So
take the example from the previous mail (with those three classes A, B
and C and two visitors, one for printing and one for displaying.
The printing visitor will typically implement two methods (yes, only
two, not three): doB: and doC:. Likewise for the display visitor.
Now comes a key point: the visitor class itself will implement the
behaviour that in order to process the A node in this hierarchy, the B
and C node has to be processed. So this behaviour (the traversal) can
be shared amongst all visitors. In this small hierarchy it is debatable
whether this is useful, but in bigger hierarchies it becomes noticeable.
Note that you could use a Strategy to have different tree-walking
strategies in this visitor (a depth-first, a breadth-first, etc.) :-)
On Thursday, March 20, 2003, at 10:53 PM, Markus Gaelli wrote:
No, they don't say that, they just say to be
carefully.
I think, it's just that if the verb is responsible for the action
and not the noun, and the "noun"-object stays stupid it might be
a bad smell...
The main question remains, if you are assigning responsibilities
in a right and balanced way.
Personally I haven't understood, why Visitors could not be seen
as Strategies (at least when you want to apply several
printing/rendering...
strategies, literally) and I am looking forward to read a
paper/article (in JOOP?)
Doru told me about, which compares Visitor with Strategy
Cheers
Markus
Am Donnerstag, 20.03.03 um 22:45 Uhr schrieb Lukas Renggli:
Roel Wuyts Software
Composition Group
roel.wuyts(a)iam.unibe.ch University of Bern,
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org
that double-dispatch is not OO too?
Lukas
--
7947
days inactive
7948
days old
7 comments
6 participants
participants (6)
-
Alexandre Bergel -
Lukas Renggli -
Markus Gaelli -
Markus Gälli -
Roel Wuyts -
Stephane Ducasse