Re: "use" clauses and Ada 95 OOP

[jsa@alexandria (Jon S Anthony)]

In article <4t349j$lll@newsbf02.news.aol.com> jamess1889@aol.com (JamesS1889) writes:

> In article <JSA.96Jul19191630@alexandria>, jsa@alexandria (Jon S Anthony)
> writes:
> 
> >What do either of you mean by "the function that is associated with X
> >at runtime" here?  In the environment we are talking about here there
> >is no "_the_ func associated with X".  X contains a value which will
> >have a type indicator which will provide access to the proper jump
> >table entry.  Since the value of X can change (e.g., in C++ or Java up
> >level assignments) the func "associated" with X can change (and not
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not specific!
> >necessarily be the one defined in the class of which X was a declared
> >instance).  Seems pretty much like the exact same issue.
> 
> You are speaking of the value of X, and you are treating func as if it
> were a specific function.

Actually, I am definitely _not_ treating func as if it were a specific
function.

> In C++ and Java, functions that operate on objects are defined
> syntactically within the definition of the object, on the same level with
> the attributes of the object.  The corollary in Ada (which would be
> illegal) would to all function definitions to appear between the "type x
> is tagged record..." and the "end record;" - sort of like what Ada95 DOES
> do with protected objects.

No, the "corollary in Ada" is that all such operations (primitive) are
those defined within the same immediate package specification as the
tagged type.  So, _only_ those within the same immediated spec are
"dispatchable" operations - just like _only_ those within a class def
(and in C++ tagged with "virtual") are dispatching (note the "able"
and "ing" suffixes!)


> In C++ and Java, you can write x.func.  In Ada95, you have to write
> Pkg2.Func(x), UNLESS you use the "use clause", which is the question this
> whole thread is about.
> 
> Now, do you understand?

Well, this still does not answer my question, but maybe it does not
matter.  I think I now see that the issue is that in Ada, dispatching
is a local issue and does _not_ occur by default - rather it occurs
for primitive ops of tagged tyes iff you pass in a "class-wide" actual
to a controlling formal parameter.  To not dispatch you simply use an
actual of a specific type and then the operation will be statically
bound.  So, dispatching or not has nothing to do with qualified names.

In Java and C++ (with"virtual"...)  dispatching is a global issue and
the default is to dispatch, and to not dispatch you have to explicitly
request non-dispatching with a qualified name.  So, you appear to have
linked up qualified name notation with explicit calls to the function
so qualified.  OK, yes, this is different than the situation in Ada
and notice that the use of "use" does not change the semantics of this
only the visual appearance.

I suppose the route that you would be more comfortable with then is the
one that I mentioned in a previous post, viz., the use of abstract base
types for any extension that provides _new_ primitive operations.  You
then use dispatching invocations only on the abstract operation.  You
would then typically (well I suppose) use qualified naming but since
the operation is abstract it would not seem "funny" that it dispatched
to wherever (based on the type indicator):

package Pkg2 is
    type T is abstract ...
    function Func ( x : T ) return ... is abstract;
...
end Pkg2;

package Pkg2.Concrete_T is
    type New_T is new T with ...        -- no longer abstract...
    function Func ( x : T ) return ...; -- no longer abstract...
...
end Pkg2.Concrete_T;

...etc...

-- Somewhere sometime later

    X : Pkg2.T'Class := ...
...
    Pkg2.Func(X);  -- Dispatch to proper func which _can't_ be
                   -- Pkg2.Func since it is _abstract_

Maybe this is jives more with your sensitivities here...

/Jon






-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com