Re: Ada is getting more popular!

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Sun, 31 Oct 2010 02:35:03 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> 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 Move  
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 same.  
So what about an access to function ? We would need a way to attach it to  
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 there  
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 the  
Size and Coordinate functions, a context, whose type may vary : we do not  
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, so  
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 from  
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 the  
second are required if we want to apply that computed layout. We may want  
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 inherit  
 from that, but instead will provide a reference to objects of these types,  
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 which  
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 be  
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 distinct  
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 to  
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_Box  
(so we will use classification), ad well an Error_Dialog_Box could simply  
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, … I am not so sure for the latter.

At least worth to note polymorphism does not implies inheritance hierarchy  
(and thus classification). But how to explicitly render this in source ?  
(I mean render, … something which clearly show the reader the intended  
usage of the polymorphism, and as usual, comments may not be enough here).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.