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: a07f3367d7,e276c1ed16429c03 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news4.google.com!feeder.news-service.com!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Ada is getting more popular! Date: Sun, 31 Oct 2010 06:02:20 +0100 Organization: Ada @ Home Message-ID: References: <14fkqzngmbae6.zhgzct559yc.dlg@40tude.net> <8732ea65-1c69-4160-9792-698c5a2e8615@g13g2000yqj.googlegroups.com> <4cc60705$0$23764$14726298@news.sunsite.dk> <4cc6753c$0$23756$14726298@news.sunsite.dk> <4cc71e08$0$23758$14726298@news.sunsite.dk> <4cc87d7a$0$23755$14726298@news.sunsite.dk> <4cc912e1$0$23761$14726298@news.sunsite.dk> NNTP-Posting-Host: gHYtk+mhCrTAX6LNXybaBQ.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 X-Notice: Filtered by postfilter v. 0.8.2 User-Agent: Opera Mail/10.63 (Win32) Xref: g2news2.google.com comp.lang.ada:15978 Date: 2010-10-31T06:02:20+01:00 List-Id: Le Sun, 31 Oct 2010 02:35:03 +0100, Yannick Duch=C3=AAne (Hibou57) = a =C3=A9crit: > May add classification is more static than composition, or at least, = > cannot evolve as easily as a construction built upon composition. About inheritance and polymorphism, which could be kept apart. Let start with the most popular example : graphic objects. Le say the graphic object have a position, a bounding rectangle and a = method to move. Why should this object be made polymorphic ? Let say we have a window manager, which needs coordinates and bounding = rectangle to layout components on a display area. OK, but does, say, a dialog box, inherit a root type which have an = abstract Coordinate function and Move procedure ? Wait a minute, the Mov= e = procedure may not be required to just compute the layout. For this = process, only the Coordinate and Size functions are needed. Back to the = = question : does the dialog box inherit a type which have Coordinate and = = Size abstract functions ? Is that really the *root* of what a dialog box= = is ? Let return it, and say, the dialog box must provide Coordinate and = = Size functions. This is not the same any more. So why this must be = polymorph : because many objects of different types must provide the sam= e. = So what about an access to function ? We would need a way to attach it t= o = a context, that is an object. We could give it a parameter, say a dialog= = parameter, but then we would need as many different function type as the= re = different object types which must provide Coordinate and Size functions.= = So we may use a tagged type, no to inherit, but instead, just to give th= e = Size and Coordinate functions, a context, whose type may vary : we do no= t = need to give multiple implementation of Size and Coordinate functions to= a = root object; this is the reverse, we have to provide to one functions, = multiple context. Technically, this ends to be the same, but logically, = = this is these are both opposite. So far : Dialog_Box needs to provide Size and Coordinate functions, and = = use a tagged type which can attach similar functions to contexts of = different types. Now, after the layout is computed, all these objects need to be moved, s= o = these object must now provide a Move procedure. And here, the same kind = of = comments applies as above can apply. But the ability to provide Size and Coordinate functions is distinct fro= m = the ability to provide a Move procedure. Why ? Because it is not needed = = for the same reason : the first are required to compute a layout, and th= e = second are required if we want to apply that computed layout. We may wan= t = to compute layouts, without any application of these, as well as we may = = apply precomputed layouts which are not computed by the application at = runtime. So, shall we define two root types, one with Size and Coordinate, and = another with Move ? Ouch, not good, because this would require multiple inheritance. So, let do it with simple inheritance : create a root type with Size and= = Coordinate, derive a new type with Move, and derive our object type from= = this latter. But why first Size + Coordinate and then Move ? Why not the= = opposite ? As these are separate requirement, there is no reason why one= = should be made more fundamental than the other. So let create a root type with Size + Coordinate + Move. But about the = cases where Move or Size + Coordinate are of strictly no use ? May an idea would be kind of proxies : define an abstract type with Size= + = Coordinate, another type with Move. Dialog_Box and peers will not inheri= t = from that, but instead will provide a reference to objects of these typ= es, = as derived types. Let call the first type Positioned and the second one = = Movable. We may have a Dialog_Box which could return a reference to a = Dialog_Box_Positioned and a Dialog_Box_Movable. Now, a Dialog_Box is not anymore rooted (so primarily is) at a type whic= h = have either Move or Size + Coordinate, and is instead what it is : a = Dialog_Box. From a semantic point of view, this seems more clear to me. = = There is just a dark point : you have to define three type to create a = Dialog_Box, instead of creating only one (requires longer source) ; but = = still makes more sens, still have a clearer semantic with no arbitrary = decision (with no justification) as expose above. This may be a way to formalize a usage of polymorphism which could not b= e = confused with classical inheritance. This polymorphism would just be a = facade to an abstraction, which would require two levels only : an = abstract type and as many concrete type as needed. This may be nice to care : when we use tagged types, are we using = inheritance tree or are we using some facades to some abstractions ? Could there be some provision to make this two concept explicitly distin= ct = in the language ? Something like a keyword which would say : one = derivation level only for concrete implementation of this abstraction = allowed ? But now what if a type would like to reuse part of the implementation of= = Dialog_Box ? It can do it via invokation of standard implementation = procedure with proper signature which would be visible for both. Again, but what if we want an Error_Dialog_Box ? Doesn't sound natural t= o = say it's particular kind of Dialog_Box ? I have no clear idea for that, = as = I would say yes, this may be legitimately a specialization of a Dialog_B= ox = (so we will use classification), ad well an Error_Dialog_Box could simpl= y = be no more than just a Dialog_Box, with style kind attributes : ex. = Warning_Style, Error_Style, Information_Style. This latter is less obvious to me. For all so far, it seems clear to me = = composition offers a clearer semantic, =E2=80=A6 I am not so sure for th= e latter. At least worth to note polymorphism does not implies inheritance hierarc= hy = (and thus classification). But how to explicitly render this in source ?= = (I mean render, =E2=80=A6 something which clearly show the reader the in= tended = usage of the polymorphism, and as usual, comments may not be enough here= ). -- = Si les chats miaulent et font autant de vocalises bizarres, c=E2=80=99es= t pas pour = les chiens.