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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,760a0492b97ae06e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-23 02:42:55 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-041-053.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: How to test object hierarchy Date: Tue, 23 Dec 2003 11:49:12 +0100 Organization: At home Message-ID: References: <93172edb.0312181024.9a536b2@posting.google.com> <49cbf610.0312211158.87338af@posting.google.com> <84ednQiB4Y5nt3qiRVn-hQ@comcast.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-041-053.arcor-ip.net (145.254.41.53) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1072176174 11380881 145.254.41.53 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:3743 Date: 2003-12-23T11:49:12+01:00 List-Id: Robert I. Eachus wrote: > Dmitry A. Kazakov wrote: > >> This is an argument in favor of implementing MD in Ada, I suppose (:-)) > > No, it is an argument that current Ada rules are just fine. You can do > multiple dispatching in Ada, and the sort of casual dispatching where > the author of the code doesn't even know that multiple dispatch is > involves works just fine. For example, instantiate a generic with a > classwide type or two as an actual type parameter. The resulting > executable may have nested dispatching, but there is no real need to > anticipate that case when writing the generic. These cases are not cases of MD. Anything that can be written using "cascading" dispatch is in fact single dispatch in one argument and class-wide in another. What is not MD, is not. > As for cases where you really NEED to understand the code in multiple > dispatching terms, these are no harder to program in Ada than in other > languages--and no easier. And they really are that hard to wrap the > mind around. There are cases which are worth the effort, but precious > few. The point is that MD is a *natural* view on any subprogam having many parameters. All other views are in fact kludges, hard to understand and very error-prone. Note that if the language is aware of MD, it can enforce necessary overridings, because it knows that they should be. Otherwise, a developer is exposed to a geometric explosion of variants, which he might be even unaware of, especially if he derives from a library type. > Another more prosaic example would be a general graphic file format > converter. I can design such a tool as a combination of a reader and a > writer with a standard intermediate representation: > > ... > declare > Temp: Intermediate_Format := Read(Input_File); > begin > Write(Temp, Output_File); > end; > > Of course I can rewrite this as: > > Write(Read(Input_File), Output_File); > > Later I might want to add a graphics format that doesn't work well with > the "standard" intermediate format. To do this, I can restructure the > existing code with a multiple dispatch format: > > procedure Process(Input: in Graphics_Format; out Graphics_Format'Class); > or > function Process(Input: Graphics_Format) return Graphics_Format'Class; > > Now I can provide a body which normally uses the old approach with > Intermediate_Format, but first checks for the special cases and handles > them with other routines. > > THAT is when it starts to get difficult to use multiple dispatch. It is > not the process of doing what I call 'casual' multiple dispatch in Ada, > that is easy. The problem is going through on an N**2 case by case > basis (or N**3 or N*M or whatever) and insuring that the approach that > is dynamically selected for that particular case is, in some sense, the > right one. And when the set of possibilities grows, adding one new > format means considering 2N-1 new cases. Right, therefore it has to be supported by the compiler! And in this case, MD on same type hierarchy, it is pretty easy to do. The compiler shall simply check that if one of 2N-1 possible overridings happens, others have to be explicitly overridden too. Also I really wish some language support for commutative operations, which would reduce the number of variants in twice. But the real problem with MD is the case of different type hierarchies. For example, stream attributes. Present implementation is obviously inconsistent. S'Write should know all stream types because it is class-wide in the Stream argument. How a developer of a type can foresee all possible streams? What if it is a library type? It is clear to me that consistency should be enforced by the language. The great problem is how. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de