Re: Dispatching in Ada95

Re: Dispatching in Ada95

[James A. Squire]

On Wed, 24 Apr 1996 22:58:40, Robert Dewar <dewar@CS.NYU.EDU> wrote:

> James Squire said
>
> "So, you do compromise and use the use clause, then.  That was my whole
> question.  The use clause *is* essential to dispatching."
>
> This is quite wrong, the use clause has to do with direct visibility and
> whether you need to use dots. It does not have anything to do with
> dispatching.

Asked and answered already.  Apparently you missed the following
exchange on the 23rd:

> On, Tue, 23 Apr 1996 04:00:50 GMT, Tucker Taft
> <stt@HENNING.CAMB.INMET.COM>
>
> > : So, you do compromise and use the use clause, then.  That was my whole
> > : question.  The use clause *is* essential to dispatching.
> >
> > No, the use clause is irrelevant to dispatching.  You can write P.F(X)
> > in a dispatching call.  Furthermore, presuming X is of type T'Class,
> > then only the "F" on "T" needs to be visible.  The "F" on T1, T2, etc.,
> > need not be visible.
>
> A couple of others have informed me of this also.  This is one fact in
> all of this that I literally did not know.  I'm glad to hear that you
> don't have use the use clause at all in order to use dispatching.  Of
> course, I probably should have guessed as much as soon as someone
> informed me that visibility to all dispatchable routines is not needed
> at compile time - the other fact that I literally did not know.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Dispatching in Ada95

[Robert Dewar]

James Squire said

"Asked and answered already.  Apparently you missed the following
exchange on the 23rd:"

Not at all, I didn't miss it, but it arrived at my news host AFTER I had
posted my reply. One thing I think that many people do not understand
about news is that the arrival time of individual articles can vary
VERY widely (matter of days) from one site to another.

Re: Dispatching in Ada95

[James A. Squire]

On, Tue, 23 Apr 1996 04:00:50 GMT, Tucker Taft
<stt@HENNING.CAMB.INMET.COM>

> No, not directly visible.  Direct visibility is required only if you want
> to write "F(X)"; just plain "visibility" is required if you are willing to
> write "P.F(X)."

Sorry, I was using peculiar semantics in which:  P.F(X) makes F(X)
directly visible.  In any event, I agree with your statement.

> : > Let's take an example. We create a package AAA which defines a class A
> : > as well as a Create function, and a Get_Info function.
>
> : [example snipped]
>
> : > Now, our main procedure T. T withes AAA, BBB and Text_IO, and uses all
> : > of them except BBB.
>
> : So, you do compromise and use the use clause, then.  That was my whole
> : question.  The use clause *is* essential to dispatching.
>
> No, the use clause is irrelevant to dispatching.  You can write P.F(X)
> in a dispatching call.  Furthermore, presuming X is of type T'Class,
> then only the "F" on "T" needs to be visible.  The "F" on T1, T2, etc.,
> need not be visible.

A couple of others have informed me of this also.  This is one fact in
all of this that I literally did not know.  I'm glad to hear that you
don't have use the use clause at all in order to use dispatching.  Of
course, I probably should have guessed as much as soon as someone
informed me that visibility to all dispatchable routines is not needed
at compile time - the other fact that I literally did not know.

> Dispatching has nothing to do with "use" clauses, and the only
> thing that has to be visible at compile-time (and not necessarily
> directly visible) is the primitive operation of the (root) type T, presuming
> the operand is of (compile-time) type T'Class.

This, it would seem, is important.  In other words, you can't just
specify any old primitive.  It has to be a primitive of the root type.

Thanks again for the help.  I think what many have interpreted as
confusion is actually my attempt to push people on this newsgroup to do
a better job of listening to my original questions.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Dispatching in Ada95

[James A. Squire]

On Fri, 19 Apr 1996 13:34:34, Samuel Tardieu <sam@INF.ENST.FR> wrote:

> >>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:
>
> James> Unless I am totally dense, in order for dispatching to work in
> James> this example as printed on page II-8, there is one vital
> James> element (which of course is left out of the example on II-8):
> James> "use New_Alert_System; use Emergency_Alert_System;"
>
> James> Otherwise, dispatching doesn't work, because once the 'Class
> James> attribute is used to figure out the actual type of the
> James> Alert'Class parameter in a given instance, and then the Ada83
> James> rules kick in: check all overloaded subprograms _which are
> James> directly visible_ at that point in time and pick the only one
> James> that matches the parameter profile.
>
> I wouldn't say you're totally dense since I don't know you, but I
> think you have misunderstood how dispatching works :)
>
> You're right in saying that it will check a subprogram which is
> directly visible (if you don't give a prefix). But if your parameter
> is of a class-wide type, only a subprogram with the base type of this
> class-wide type needs to be visible.

Correction:  Directly visible.

> Let's take an example. We create a package AAA which defines a class A
> as well as a Create function, and a Get_Info function.

[example snipped]

> Now, our main procedure T. T withes AAA, BBB and Text_IO, and uses all
> of them except BBB.

So, you do compromise and use the use clause, then.  That was my whole
question.  The use clause *is* essential to dispatching.

Thank you for answering my question.  Just another "gotcha" of Ada95 to
note for future reference.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Dispatching in Ada95

[Tucker Taft]

James A. Squire (m193884@CSEHP3.MDC.COM) wrote:
: On Fri, 19 Apr 1996 13:34:34, Samuel Tardieu <sam@INF.ENST.FR> wrote:

: > >>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:

: > You're right in saying that it will check a subprogram which is
: > directly visible (if you don't give a prefix). But if your parameter
: > is of a class-wide type, only a subprogram with the base type of this
: > class-wide type needs to be visible.

: Correction:  Directly visible.

No, not directly visible.  Direct visibility is required only if you want
to write "F(X)"; just plain "visibility" is required if you are willing to
write "P.F(X)."

In any case, dispatching has nothing to do with visibility.

: > Let's take an example. We create a package AAA which defines a class A
: > as well as a Create function, and a Get_Info function.

: [example snipped]

: > Now, our main procedure T. T withes AAA, BBB and Text_IO, and uses all
: > of them except BBB.

: So, you do compromise and use the use clause, then.  That was my whole
: question.  The use clause *is* essential to dispatching.

No, the use clause is irrelevant to dispatching.  You can write P.F(X)
in a dispatching call.  Furthermore, presuming X is of type T'Class,
then only the "F" on "T" needs to be visible.  The "F" on T1, T2, etc.,
need not be visible.

: Thank you for answering my question.  Just another "gotcha" of Ada95 to
: note for future reference.

I fear these answers have only served to confuse you more ...

To reiterate:

Dispatching happens at run-time, whenever the controlling operand is 
class-wide (or otherwise "dynamically tagged") in a call on a primitive
subprogram of a tagged type.  

Dispatching has nothing to do with "use" clauses, and the only 
thing that has to be visible at compile-time (and not necessarily 
directly visible) is the primitive operation of the (root) type T, presuming 
the operand is of (compile-time) type T'Class.

: James Squire
: MDA Avionics Tools & Processes
: ja_squire@csehp3.mdc.com

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Dispatching in Ada95

[Robert Dewar]

James Squire said

"So, you do compromise and use the use clause, then.  That was my whole
question.  The use clause *is* essential to dispatching."

This is quite wrong, the use clause has to do with direct visibility and
whether you need to use dots. It does not have anything to do with
dispatching.

Re: Dispatching in Ada95

[Jon S Anthony]

In article <317BCF1F.6542@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> writes:

> > You're right in saying that it will check a subprogram which is
> > directly visible (if you don't give a prefix). But if your parameter
> > is of a class-wide type, only a subprogram with the base type of this
> > class-wide type needs to be visible.
> 
> Correction:  Directly visible.

Correction, not directly visible.  And dispatching has nothing to do
with visibility anyway.  Why do you think so??????


> > Now, our main procedure T. T withes AAA, BBB and Text_IO, and uses all
> > of them except BBB.
> 
> So, you do compromise and use the use clause, then.  That was my whole
> question.  The use clause *is* essential to dispatching.

No.  Not only is the use clause _NOT_ essential, it has nothing to do
with it.  Dispatching is a runtime thing based on the dynamic type
(tag) of the operands of the particular invocation.  You're just plain
confused (for some reason...)


> Thank you for answering my question.  Just another "gotcha" of Ada95 to
> note for future reference.

Unfortunately, you still don't get it.  There is no "gotcha" here.

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

617.484.3383
jsa@organon.com

Dispatching in Ada95

[James A. Squire]

I'm told that in object oriented programming like C++, one of the nice
aspects of the language is that dispatching occurs based on the object
instance that is being used - that in fact the method is prefixed by the
object instance and that is all it takes to find the code that needs to
be executed.

Look at the Ada95 Rationale, especially with respect to the
New_Alert_System example on page II-6 and the extension
Emergency_Alert_System on II-7, Class Wide programming is presented as
the way in which dispatching is implemented.

Unless I am totally dense, in order for dispatching to work in this
example as printed on page II-8, there is one vital element (which of
course is left out of the example on II-8):  "use New_Alert_System; use
Emergency_Alert_System;"

Otherwise, dispatching doesn't work, because once the 'Class attribute
is used to figure out the actual type of the Alert'Class parameter in a
given instance, and then the Ada83 rules kick in:  check all overloaded
subprograms _which are directly visible_ at that point in time and pick
the only one that matches the parameter profile.  Without the use
clauses, I presume something nasty like Program_Error would be raised.

How do people handle this?  I'm curious, especially since type extension
is intended to be possible without having to recompile the original
package.  Do you corrupt your application by using the use clause?  Or
do you work around this problem some other way?

Or am I missing something?
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Dispatching in Ada95

[Robert A Duff]

In article <3176FEBF.5D3@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>I'm told that in object oriented programming like C++, one of the nice
>...

For the most part, the Ada and C++ dispatching features are pretty much
the same.  They use a different syntax to indicate which object you're
dispatching on.

>Unless I am totally dense, in order for dispatching to work in this
>example as printed on page II-8, there is one vital element (which of
>course is left out of the example on II-8):  "use New_Alert_System; use
>Emergency_Alert_System;"

No.  Dispatching is a run-time action that has nothing to do with
visibility.  You can dispatch to a subprogram this is not visible to you
at compile time.  In fact, that's the whole point: you want to avoid
depending on what you're calling.

- Bob

Re: Dispatching in Ada95

[Samuel Tardieu]

>>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:

James> Unless I am totally dense, in order for dispatching to work in
James> this example as printed on page II-8, there is one vital
James> element (which of course is left out of the example on II-8):
James> "use New_Alert_System; use Emergency_Alert_System;"

James> Otherwise, dispatching doesn't work, because once the 'Class
James> attribute is used to figure out the actual type of the
James> Alert'Class parameter in a given instance, and then the Ada83
James> rules kick in: check all overloaded subprograms _which are
James> directly visible_ at that point in time and pick the only one
James> that matches the parameter profile.

I wouldn't say you're totally dense since I don't know you, but I
think you have misunderstood how dispatching works :)

You're right in saying that it will check a subprogram which is
directly visible (if you don't give a prefix). But if your parameter
is of a class-wide type, only a subprogram with the base type of this
class-wide type needs to be visible.

Let's take an example. We create a package AAA which defines a class A
as well as a Create function, and a Get_Info function.

package AAA is
   type A is tagged private;
   function Create return A;
   function Get_Info (X : A) return String;
private
   ...
end AAA;

package body AAA is
   function Create return A is
   begin
      ...
   end Create;
   function Get_Info (X : A) return String is
   begin
      return "Type A object";
   end Get_Info;
end AAA;

Then we create a BBB package which defined a class B (derived from
AAA.A). This class gets an overloaded Get_Internal_Info method.

with AAA;
package BBB is
   type B is new AAA.A with private;
   function Create return B;
   function Get_Info (X : B) return String;
private
   ...
end BBB;

package body BBB is
   function Create return B is
   begin
      ...
   end Create;
   function Get_Info (X : B) return String is
   begin
      return "Type B object";
   end Get_Info;
end BBB;

Now, our main procedure T. T withes AAA, BBB and Text_IO, and uses all
of them except BBB.

An object of type A'Class is declared, and initialized to an object of
type B. This is possible because B is derived from A.

When Get_Info is called, the right one (B's one) is executed, although
the one which is visible is AAA's one.

with AAA, BBB, Ada.Text_IO;
use AAA, Ada.Text_IO;
procedure T is
   Var : constant A'Class := BBB.Create;
begin
   Put_Line (Get_Info (Var));
end T;

How does it work ? Simple : since Var is of a type A'Class, and a
Get_Info function taking an argument of type A is in the scope, then a
dynamic resolution will occur to check if a deeper Get_Info (on the
path A->B) exists. One is found (BBB.Get_Info, which takes an argument
of type B) and gets called, even if it's not directly visible.

Note that if Var was declared as:

  Var : constant BBB.B := BBB.Create;

the program wouldn't compile, because no Get_Info with an argument of
type B is directly visible.

I hope I've been clear enough and not too confusing :)

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire