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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,57c2a52b53b360c2 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news3.google.com!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!.POSTED!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Multiple dispatch Date: Sat, 11 Jun 2011 15:19:00 +0200 Organization: Ada @ Home Message-ID: References: <7loar137gjid$.qrn6ghii6ee$.dlg@40tude.net> NNTP-Posting-Host: fGpkzlUfcOSQVUiZJOXhgg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/11.11 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news2.google.com comp.lang.ada:20717 Date: 2011-06-11T15:19:00+02:00 List-Id: Le Sat, 11 Jun 2011 13:52:05 +0200, Dmitry A. Kazakov = a =C3=A9crit: > Yes, that looks like the usual pattern for protocols and similar stuff= , > when objects do not depend on the container. What kind of dependencies do you have in mind ? Object existence dependi= ng = on the container ? Or object's properties depending on the container ? I was trying to figure many cases (in an attempt to invalidate the desig= n, = and fail with that, to prove this is the good design); among others, thi= s = one : if the container know enough about the object types because it is = = fully dedicated to these object types, one may argue the container could= = also serialize objects on its own side. However, this would imply a swit= ch = on object types, which is not clean, due to an implicit though behind = this: dispatching calls and switch are somewhat similar things, however = = with an important difference, which is that with dispatching calls, the = = corresponding switch is always owned by (under the responsibility of) th= e = type on which the switch is to be done, while with the switch approach, = = anything could do a switch. The former more enforce structuring. Another approach, with a more concrete-like example (which is not the on= e = I am actually dealing with=E2=80=A6 I wont tell more, as I prefer to kee= p this = talk as much abstract as possible) : you have two types, one for a = character string and one for an array of numbers, and two containers. Sa= y = one container is a file and the other is anything else you wish (could b= e = a serial communication wire plugged to some device, as an example). Let = = say there are two way to serialize each type. For the string, there is a= = C-like serialization, that is, all characters first, with a final Unicod= e = U+0000, and a Pascal-like serialization, with a length first and then th= e = all characters. Let say there is something similar with the array of = numbers : it could either be serialized with a kind of null terminator, = = and the other way, starting with its length and then its numbers. Say ea= ch = of the two container expect one or the other serialization. This case seems more ambiguous at first sight, at it could seems as much= = easy and clean to dispatch on either the container or the object. Eh, bu= t = only one container type know about what null terminators are and only on= e = know about what lengths are. Now let say none of the array of numbers or= = the character strings, know about what null terminators are. With such a= = case, wouldn't it be better to dispatch first on the container ? Is that= = the kind of dependency you though about ? > The opposite case is > represented by drivers, when objects are maintained by the driver, you= > might first dispatch on the driver type and then on the type of its > objects. I tried to figure out this one, but couldn't. Could you tell about a tin= y = and short example ? -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [Ep= igrams on = Programming =E2=80=94 Alan J. =E2=80=94 P. Yale University] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [Idem] =E2=80=9Cc++; /* this makes c bigger but returns the old value */=E2=80=9D= [Anonymous]