comp.lang.ada
 help / color / mirror / Atom feed
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Subject: Re: issue with implementing a visitor design pattern
Date: 24 Jan 2004 16:44:02 -0500
Date: 2004-01-24T16:44:02-05:00	[thread overview]
Message-ID: <wcc4qult42l.fsf@shell01.TheWorld.com> (raw)
In-Reply-To: MrNoSpam-AA0930.07381425012004@news-server.bigpond.net.au

Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes:

> Robert A Duff wrote:
> > I agree.  In fact, I'd say "visitor" is my least favorite design pattern
> > of the ones in the Gamma et al book.  "Visitor" has all the
> > disadvantages of a case statement (over dispatching calls),
> > with none of the advantages!
> 
> If you have two orthoganal classifications (object and function) and
> you need to (effectively) double dispatch, the visitor pattern is 
> quite useful. Not quite sure how else you would achieve it in Ada.

You can have a variant record, with a discriminant of an enumeration
type, and use case statements on the discriminant.  You can even use
subtypes of the enumeration in the case statements.  The way things were
done in the olden days.  ;-)

You have to decide which of "adding new types" or "adding new operations"
is the more important issue.  If the former, the normal OOP style is
appropriate.  If the latter, case statements are appropriate.

My objection to the "visitor" pattern is that it simulates case
statements, but with a whole lot of verbose mechanistic code.
And it retains all the disadvantages of the case-statement style.

Now, OO advocates will tell us that case statements are evil -- one
ought to define dispatching operations, so adding a new type (or
"class") will not require editing all those case statements.
Well, that's quite true in the normal case where adding new types is the
main issue.  But when you use the "visitor" pattern, you've got
essentially the same issue of editing all the operations to handle the
new case.

I suspect much of OO advocates' hatred of case statements comes from
languages where case/switch statements automatically default to
something-or-other.  But Ada largely solves that problem via its
full-coverage rule (assuming you don't evilly use 'when others').  You
still have to edit all the case statements, which is particularly bad if
we're talking about a widely-used library, but at least in Ada, the
compiler tells you which case statements have missing cases.

If you want to mix the two styles, you're kind of stuck (in Ada, and in
pretty much every other OOP language).  You have to use the visitor
pattern.  If Ada allowed case statements on the 'Tag field of class-wide
objects, then things would be much easier.  OO advocates don't like
explicit tests on the 'Tag, and that's usually right, but when it's
necessary, I claim a simple case statement would be preferable to the
"visitor" pattern, which does essentially the same thing, but with a
whole lot of extra baggage.

Adding "case on 'Tag" to Ada would not be trivial.  One would have to
reconcile the open-ended type extension capability of tagged types with
the full-coverage rules of case statements.

- Bob



  reply	other threads:[~2004-01-24 21:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-15 19:22 issue with implementing a visitor design pattern cl1
2004-01-17  3:41 ` Robert I. Eachus
2004-01-17 21:24   ` Robert A Duff
2004-01-24 20:38     ` Dale Stanbrough
2004-01-24 21:44       ` Robert A Duff [this message]
2004-01-26  8:34         ` Dmitry A. Kazakov
2004-01-26 20:18           ` Robert A Duff
2004-01-27  8:36             ` Dmitry A. Kazakov
2004-02-01  0:32               ` Georg Bauhaus
2004-01-17 23:05   ` cl1
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox