Re: Procedure types and dynamic binding

[billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)]

From article <4204@enea.se>, by sommar@enea.se (Erland Sommarskog):
> Just for discussion: If we should make Ada an object-oriented langauge,
> what should we add? Quite obvious seems package types to get classes.

    I'd think classes would be defined a bit differently!  A package
    could contain declarations of variables, and we certainly don't want
    variables included in a class definition (where class is defined as
    an abstraction over types, e.g., FRUIT as an abstraction over APPLEs,
    ORANGEs, etc.).  A class of types would consist of the name of the class,
    in conjunction with a set of operations which must be available over
    a given type in order for it to be considered a member of the class.

    Then the use of generics would be reduced substantially; we could 
    simply write

       function MAKE_JUICE (OUT_OF : in out FRUIT) return JUICE;
 
    and this would operate on any type of object (APPLEs, ORANGEs, etc.)
    which satisfied the definition of a FRUIT.  There would still be a
    need for generics in situations where values or objects are required
    as generic parameters.

    (BTW, the above example is also an example of why the stupid rule
    about functions having only "in" parameters needs to be repealed...) 
           
> But for inheritance we want all attributes, also those who do not 
> appear in the specification part (or?), and particulary we probably 
> want to have access to private types internal structure. 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    One of the most fundamental aspects of the ADT paradigm is that
    an object is known to the outside world only as a type definition
    and a set of predefined operations.  This provides the independence
    which allows us to compile specifications and implementations separately.
    Access to the internal structure of a private type violates the entire
    concept of a "private" type.  

    To achieve this effect, one can simply declare the type in question 
    as a visible type rather than a private type.  In other words, simply 
    avoid using private types.  Be warned, however, that terrible compilation 
    dependencies will result, and you will lose the freedom to replace one 
    implementation with another; in short, the method is NOT recommended 
    for serious use, and is presented only as a theoretical means of achieving 
    what you seek (in my view, misguidedly).
 
> Probably we need delaration a la Eiffel, [...]

    Gee, why don't we just make "Ada" an alias for "Eiffel"?   :-)  :-(

    Seriously though, there *is* a comp.lang.eiffel.  Perhaps you 
    would feel more at home there rather than in comp.lang.ada.

> With the risk of saying something completely obvious: if you want variable
> user-provided operations the following example with a tree-traversing
> illustrates:
> 
>    Generic
>       Type Data_type is limited private;
>       With procedure Assign(A : in out Data_type; B : in Data_type);
>       With function "<"(A, B : Data_type) return boolean is <>;
>       With function ">"(A, B : Data_type) return boolean is <>;
>    Package Binary_trees is
>       Type Tree_type is private;        -- A tree with sorted data.
>       Type Node_type is private;        -- A node in such a tree.
>       ...
>       Generic
>          With Procedure Treat(Node : in     Node_type;  
>                               Data : in out Data_type); 
>       Procedure Traverse_forward(Tree : Tree_type);
> 
> (By the way, an example like the one above should be added to the validation
> suite if it's not already there. A PC compiler I played with choked on the 
> code above, and I believe it is/was validated.)

     Why does Node need to be a parameter of Treat?  All you need is
     something that will treat Data once Traverse_Forward has extracted
     it from the Node.  Once you've removed the unnecessary parameter,
     your package should compile perfectly.



                                            Bill Wolfe

                                    wtwolfe@hubcap.clemson.edu