From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4687ad82921cf6ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-24 13:44:03 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news-out.visi.com!petbe.visi.com!newshub.northeast.verio.net!verio!newsfeed.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: issue with implementing a visitor design pattern Date: 24 Jan 2004 16:44:02 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <100dqeul3pqiua0@corp.supernews.com> NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1074980642 30184 192.74.137.185 (24 Jan 2004 21:44:02 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sat, 24 Jan 2004 21:44:02 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:4787 Date: 2004-01-24T16:44:02-05:00 List-Id: Dale Stanbrough 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