20 Mar
2003
20 Mar
'03
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.