Re: Ada 95 OOP questions

Re: Ada 95 OOP questions

[W. Wesley Groleau (Wes)]

I offer a compromise to anyone who wants Ada to be more obvious about
the relationship between an object/class/type and its methods/operations.

If you get a warm fuzzy from

    class Person
    {
       Eat();
       Walk();
       Talk();
    }

perhaps you would feel good about

    protected Person is
       entry     Eat;
       procedure Walk ( To    : in Location );
       function  Talk ( About : Subject ) return Words;
    private
       Name : Name_Type;
    end Person;

And you can even put persons in arrays, record fields, or linked lists.
You can pass them as parameters, and each Person knows his/her name without
having to call it "my.Name"

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Ada 95 OOP questions

[Robert Dewar]

Wes says

"I offer a compromise to anyone who wants Ada to be more obvious about
the relationship between an object/class/type and its methods/operations."

And then suggests misusing protected types for this purpose. Why misuse?
Because protected types in Ada 95 are not a general abstraction mechnamism,
but rather a low level construct with severe restrictions on what can be
done inside the protected operations. The whole idea of protected operations
is that the operations themsleves should be short simple operations, and in
particular they cannot perform potentially blocking operations.

So advising the use of protected objects as a general replacement for
a class abstraction will pretty quickly get people into trouble!
Furthermore, they are likely to not realize that they are in trouble,
since compilers are not required to check dynamically for violating the
no-potentially-blocking-operations requiremens, and therefore you can
easily end up writing non-portable code without realizing it.

Let me give an example, suppose you have a library sort routine. Unknown
to you, the body of this sort declares tasks. Calling this sort routine
from within a protected operation means that your program has a bounded
error, and it might work on one compiler, and mysteriously deadlock on
some other implementation, or raise Program_Error (in practice the worry
is raising Program_Error, since although 9.5.1(17) allows deadlock to
occur, it probably is the intention that this be alloowed only if it
naturally makes sense that deadlock could arrive