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,start X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news3.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!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: Multiple dispatch Date: Sat, 11 Jun 2011 12:13:21 +0200 Organization: Ada @ Home Message-ID: 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: g2news1.google.com comp.lang.ada:19743 Date: 2011-06-11T12:13:21+02:00 List-Id: Hi peoples, Hi Ada world, In your opinion, what is the best known design pattern for multiple = dispatch in Ada ? (as far as I know, there is no way to get multiple = dispatching in Ada the direct way). As with any design matters, an answer to this question will probably = depends on the concrete case, so here is an overview of the concrete = matter: it deals with serialization. An example: you have multiple object of different types rooted at a some= = root type; you also have multiple containers of different types too, als= o = rooted at another root type. Now, say objects are all to have a = serialization methods, a different one for each type. This could be = dispatching, OK, except that you have the requirement these objects are = = also to be serialized a way or another, depending on the container which= = will hold the serialized datas. Add to this that you can't change this, = = because this is part of some standard or any other kind of things alread= y = fixed. Say Object_1_Type, to be serialized to Container_1_Type, will use = Method_1_1 =E2=80=A6 Object_1_Type, to be serialized to Container_2_Type, will use= Method_1_2 =E2=80=A6 Object_2_Type, to be serialized to Container_1_Type, will use = Method_2_1 =E2=80=A6 Object_2_Type, to be serialized to Container_2_Type, will use = Method_2_2 =E2=80=A6 and so on A quick solution could be : 1) Define two methods for object : one would be Serialize_To_Container_1= = and Serialize_To_Container_2. 2) Then, a master Serialize method could get two parameters, one object = = and one container, 3) This method would discriminate on container's type, so would invoke = either Serialize_To_Container_1 or Serialize_To_Container_1 depending on= = the container's type, and this call would be dispatching on object's typ= e. OK, but why not the opposite ? And then, where the master dispatcher = should reside ? In the module defining objects ? In the module defining = = containers ? In a third module ? Who should own the knowledge about = serialization ? I feel it's natural to say, Objects, of course; but this= = also requires dispatching on container's types=E2=80=A6 Still seems natu= ral the = serialization should be driven by objects, at least because objects to b= e = serialized may hold private stuff, or else are the only ones to know whi= ch = of their properties are to be stored and which are to be derived from th= e = ones stored. Alternatively, may be a seed of a solution : the containers would define= = some serialization primitives for some basic property types objects are = = made of, and objects could request the container to provide these method= , = via dispatching calls. This would end into=E2=80=A6 Steps for the serialization of an object to a container : 1) Determine the object serialization method to use depending on its typ= e. 2) The object is composed of properties of types Property_1_Type, = Property_2_Type, and so on. 3) The containers provides methods Serialize_Property_Type_1, = Serialize_Property_Type_2, and so on. 4) The object's serialization method invokes these container's methods, = = via dispatching calls. Seems OK ? Any one see a better design pattern ? Do someone see somethin= g = wrong with this repartitions of knowledge and responsibilities between = modules ? -- = =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]