"use" clauses and Ada 95 OOP

"use" clauses and Ada 95 OOP

[Mitch Gart]

In Ada 95 OOP we can have the situation where a call

    pkg1.func(x)

dispatches at runtime to

    pkg2.func(x)

because x is a classwide tagged type whose base type is in pkg1 but whose 
runtime tag says it's in fact a derived type in pkg2.

It seems to me that this notation is misleading because a reader might
think that the function in pkg1 will be executed.  

Therefore with tagged types I have adopted the style of always using
"use" clauses and writing the call

    func(x);

in the source code.  This seems less misleading to me.  I never used to
use "use" clauses in Ada 83 but I now use them a lot in Ada 95 when 
calling dispatching operations.

Have other people adopted this style?  Comments?  People who have written
coding standards which say "don't use 'use' clauses", do you think this
rule is still a good idea with Ada 95 dispatching?

To me the C++/Java syntax

    x.func

seems clearer than the Ada syntax in this case because what is being
called is the function that is associated with X at runtime, rather than
the function that comes from a given package.

-- Mitch Gart 
-- mg@inmet.com

Re: "use" clauses and Ada 95 OOP

[James A. Squire]

Mitch Gart wrote:

> In Ada 95 OOP we can have the situation where a call
>
>     pkg1.func(x)
>
> dispatches at runtime to
>
>     pkg2.func(x)
>
> because x is a classwide tagged type whose base type is in pkg1 but whose
> runtime tag says it's in fact a derived type in pkg2.
>
> It seems to me that this notation is misleading because a reader might
> think that the function in pkg1 will be executed.
>
> Therefore with tagged types I have adopted the style of always using
> "use" clauses and writing the call
>
>     func(x);
>
> in the source code.  This seems less misleading to me.  I never used to
> use "use" clauses in Ada 83 but I now use them a lot in Ada 95 when
> calling dispatching operations.

Hmm... this sounds familiar to me...  amazingly like a query I brought
up a while back when I apparently didn't understand the underlying
semantics of the dispatching call.

> Have other people adopted this style?  Comments?  People who have written
> coding standards which say "don't use 'use' clauses", do you think this
> rule is still a good idea with Ada 95 dispatching?

Well, we qualify under your third question here.  To me the problem with
the use clause is that it is tempting to take advantage of in unintended
ways, which are hard to check for in code reviews.  Your suggestion
doesn't change that, as compelling as the case probably is.

Of course, it is perhaps just as hard to enforce commentary on a
dispatching call to alert the maintainer that a routine in pkg2 might be
called, so .... interesting dilemma.

> To me the C++/Java syntax
>
>     x.func
>
> seems clearer than the Ada syntax in this case because what is being
> called is the function that is associated with X at runtime, rather than
> the function that comes from a given package.

Indeed, that is a drawback that was mentioned in our group by someone
who is familiar with C++.  I can't argue with it at all.
--
James Squire                             mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com/
Opinions expressed here are my own and NOT my company's
"Nice shark...pretty shark..."
        -- Londo, "The Gathering"

Re: "use" clauses and Ada 95 OOP

[Stephen Schmid]

Mitch Gart wrote:
> 
> > To me the C++/Java syntax
> >
> >     x.func
> >
> > seems clearer than the Ada syntax in this case because what is being
> > called is the function that is associated with X at runtime, rather than
> > the function that comes from a given package.
> 

The above call in C++ does not mean that the function associated with
the class X will get called at runtime.  If x is a reference to a class,
and func is a virtual function, then x.func will 'dispatch' (to use an Ada
term) to the function corresponding to whatever class x happens to refer
to at runtime, which could be x or any subclass of x, so the situation is
similar to that which occurs in Ada.


> > In Ada 95 OOP we can have the situation where a call
> >
> >     pkg1.func(x)
> >
> > dispatches at runtime to
> >
> >     pkg2.func(x)
> >
> > It seems to me that this notation is misleading because a reader might
> > think that the function in pkg1 will be executed.
> >

I don't think this is misleading, and I would argue in favor of not using 
the use clause.  With the use clause, the reader has no clue as to
which function is being called without checking the context clauses, and
there is greater opportunity for error.  You are giving the reader _less_
information, which cannot be helpful.  Including the package name gives
the reader a starting point to determine what functions may be called at
runtime.  In a language with run-time dispatching, that is the most that
you can do.  

Re: "use" clauses and Ada 95 OOP

[Mitch Gart]

Stephen Schmid (schmid@alta.ide.com) wrote:

: Mitch Gart wrote:
: > 
: > > To me the C++/Java syntax
: > >
: > >     x.func
: > >
: > > seems clearer than the Ada syntax in this case because what is being
: > > called is the function that is associated with X at runtime, rather than
: > > the function that comes from a given package.
: > 

: The above call in C++ does not mean that the function associated with
: the class X will get called at runtime.  If x is a reference to a class,
: and func is a virtual function, then x.func will 'dispatch' (to use an Ada
: term) to the function corresponding to whatever class x happens to refer
: to at runtime, which could be x or any subclass of x, so the situation is
: similar to that which occurs in Ada.

Yes the calls dispatch, in Ada 95 and C++/Java.

But my point is that a naive Ada 95 reader might think that the call
  
    pkg1.func(x) 

calls the code that is in the body of pkg1.  The syntax in fact 
implies that strongly.  To know it's not true a reader has to look
at the spec of pkg1 and figure out that x is a tagged type and
func is a primitive operation on a variable or anonymous access 
type, in order to know that the call is dispatching.

In Ada 83 if a reader sees the call

    pkg1.func

he can look at the body of pkg1 to see what statements will be executed.
In Ada 95 he must also look at the spec of pkg1, to find the type 
declaration of X, to know whether the call is dispatching.


: > > In Ada 95 OOP we can have the situation where a call
: > >
: > >     pkg1.func(x)
: > >
: > > dispatches at runtime to
: > >
: > >     pkg2.func(x)
: > >
: > > It seems to me that this notation is misleading because a reader might
: > > think that the function in pkg1 will be executed.
: > >

: I don't think this is misleading, and I would argue in favor of not using 
: the use clause.  With the use clause, the reader has no clue as to
: which function is being called without checking the context clauses, and
: there is greater opportunity for error.  You are giving the reader _less_
: information, which cannot be helpful.  Including the package name gives
: the reader a starting point to determine what functions may be called at
: runtime.  In a language with run-time dispatching, that is the most that
: you can do.  

The choice is between giving the reader less information, versus giving him
misleading information.

- Mitch

Re: "use" clauses and Ada 95 OOP

[Kevin J. Weise]

mg@asp.camb.inmet.com (Mitch Gart) wrote:
>
>But my point is that a naive Ada 95 reader might think that the call
>  
>    pkg1.func(x) 
>
>calls the code that is in the body of pkg1.  The syntax in fact 
>implies that strongly.  To know it's not true a reader has to look
>at the spec of pkg1 and figure out that x is a tagged type and
>func is a primitive operation on a variable or anonymous access 
>type, in order to know that the call is dispatching.
>

(My note:  original example involved Java syntax and semantics, which 
I don't know, but which I am assuming will be sufficiently similar to 
C++)

What about the point that a naive C++ reader might think that the 
call

     x.func

calls the code that is in the class of x (say, class X).  The syntax, 
in fact, implies that strongly.  To know its not true, the reader has 
to look at the public part of class X and figure out that it inherits 
class Y (and maybe even more classes), then look at the public part 
of class Y (& other inherited classes), and then the classes that 
those classes inherit, and so on, until it finds the class in which 
the function is introduced.

Does not Java class syntax & semantics behave in the same (or 
similar) fashion?

> In Ada 95 OOP we can have the situation where a call
>
>     pkg1.func(x)
>
> dispatches at runtime to
>
>     pkg2.func(x)
>
> It seems to me that this notation is misleading because a 
> reader might think that the function in pkg1 will be executed.
>

Unless I'm seriously missing something here, the function in pkg1 
will be executed if in fact there *is* one in pkg1.  If there isn't, 
and the user doesn't have detailed knowledge of the derivation of x, 
then the user has to go looking for where func actually is defined.  
I see no real difference between this and the class-based model.

>
>The choice is between giving the reader less information, versus 
>giving him misleading information.
>
>- Mitch

Indeed, it is misleading only to someone who doesn't bother to find 
out what the syntax & semantics are, & relate it to what s/he already 
knows in other languages.

---------------------------------------------------------------------
Kevin J. Weise                email:  kweise@sed.redstone.army.mil
COLSA Corp.                   voice:  (205) 842-9083
Huntsville, AL 

.. standard disclaimers apply

Re: "use" clauses and Ada 95 OOP

[JamesS1889]

In article <4t2qib$f0o@michp1.redstone.army.mil>, "Kevin J. Weise"
<kweise@c3i-ccmail.sed.redstone.army.mil> writes:

>Unless I'm seriously missing something here, the function in pkg1 
>will be executed if in fact there *is* one in pkg1.  If there isn't, 
>and the user doesn't have detailed knowledge of the derivation of x, 
>then the user has to go looking for where func actually is defined.  
>I see no real difference between this and the class-based model.

Not necessarily in the context of the example.  It was a dispatching call,
therefore, the one that gets called is based on the tag value of x at that
moment.  Pkg1 in fact, must be the package where the root type of the
class is defined.  That is it's only purporse.

James Squire                                      
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com
Opinions expressed here are my own and NOT my company's
"Only one Earth Captain has ever survived battle with a Minbari fleet.  He
is behind me.
You are in front of me.  If you value your lives, be somewhere else!"
           -- Delenn, "Severed Dreams"

Re: "use" clauses and Ada 95 OOP

[Kevin J. Weise]

mg@asp.camb.inmet.com (Mitch Gart) wrote:
>
>But my point is that a naive Ada 95 reader might think that the call
>  
>    pkg1.func(x) 
>
>calls the code that is in the body of pkg1.  The syntax in fact 
>implies that strongly.  To know it's not true a reader has to look
>at the spec of pkg1 and figure out that x is a tagged type and
>func is a primitive operation on a variable or anonymous access 
>type, in order to know that the call is dispatching.
>

(My note:  original example involved Java syntax and semantics, which 
I don't know, but which I am assuming will be sufficiently similar to 
C++)

What about the point that a naive C++ reader might think that the 
call

     x.func

calls the code that is in the class of x (say, class X).  The syntax, 
in fact, implies that strongly.  To know its not true, the reader has 
to look at the public part of class X and figure out that it inherits 
class Y (and maybe even more classes), then look at the public part 
of class Y (& other inherited classes), and then the classes that 
those classes inherit, and so on, until it finds the class in which 
the function is introduced.

Does not Java class syntax & semantics behave in the same (or 
similar) fashion?

> In Ada 95 OOP we can have the situation where a call
>
>     pkg1.func(x)
>
> dispatches at runtime to
>
>     pkg2.func(x)
>
> It seems to me that this notation is misleading because a 
> reader might think that the function in pkg1 will be executed.
>

Unless I'm seriously missing something here, the function in pkg1 
will be executed if in fact there *is* one in pkg1.  If there isn't, 
and the user doesn't have detailed knowledge of the derivation of x, 
then the user has to go looking for where func actually is defined.  
I see no real difference between this and the class-based model.

>
>The choice is between giving the reader less information, versus 
>giving him misleading information.
>
>- Mitch

Indeed, it is misleading only to someone who doesn't bother to find 
out what the syntax & semantics are, & relate it to what s/he already 
knows in other languages.

---------------------------------------------------------------------
Kevin J. Weise                email:  kweise@sed.redstone.army.mil
COLSA Corp.                   voice:  (205) 842-9083
Huntsville, AL 

.. standard disclaimers apply

Re: "use" clauses and Ada 95 OOP

[Robert A Duff]

In article <Duzwxx.8E1.0.-s@inmet.camb.inmet.com>,
Mitch Gart <mg@asp.camb.inmet.com> wrote:
>But my point is that a naive Ada 95 reader might think that the call
>  
>    pkg1.func(x) 
>
>calls the code that is in the body of pkg1.
...
>In Ada 83 if a reader sees the call
>
>    pkg1.func
>
>he can look at the body of pkg1 to see what statements will be executed.

But Mitch, Ada 83 doesn't have dispatching, so this isn't a fair
comparison.  In Ada 83, no matter what you write, you can tell
(statically) what body gets called (though if there are use_clauses the
analysis might be harder).  If you don't like the idea that the body
being called is unknown until run-time, then you simply don't like OOP.
It's not a syntactic matter.

Similarly, in C++, a naive user might think "x.func" calls the func in
the class of x.  The non-naive user knows that you have to look and see
if func is virtual, and if so, there's a run-time dispatch.

Both languages are similar in this regard -- some calls jump to a
particular place, and some jump to a run-time-known place.  And you
can't tell without looking at the declaration of the function being
called.  And in both languages, you have to understand the rules in
order to know which is which.

I must admit that a person who says "use_clauses are evil but
dispatching is good" is being a bit inconsistent.  Both use_clauses and
dispatching introduce some uncertainty (and flexibility).

- Bob

Re: "use" clauses and Ada 95 OOP

[Robert Dewar]

"But my point is that a naive Ada 95 reader might think that the call

    pkg1.func(x)

calls the code that is in the body of pkg1."

Well naive readers can be confused in many ways, and one possible solution
is to de-naiveify the readers :-)

If people get compile time visibility and run time dispatching access
mixed up, they are missing a fundamental principle, and will run into
other problems.

I really don't see a problem, if you don't like the above, don't use it
and use USE clauses instead. You can't have it both ways, if you want
to emphasize visibility aspects by not using USE, then you are clearly
going to have this clash.

In C++, when you "import" a type, you get all its methods visible, i,e
the primitive operations in Ada terms. 

If you want this effect in Ada, you use USE, if you don't want it, you
don't use USE. Seems simple enough to me.

P.S. I really do not know namespaces in C++ at all, do they allow this
same separation of visibility from run time accessibility (if not I would
say that is a disadvantage, not an advantage).

What you have in Ada is a choice of two approaches. I personally have
no trouble with the notation above pkg1.func(x), but if you feel that
naive readers of your code *will* have trouble with this notation, then
by all means don't use the notation!

People who have learned to be 100% allergic to USE in Ada 83 will find
some discomfort here, but that's something they bring upon themselves.
The idea behind disallowing USE clauses is that it is a GOOD THING if
it is made VERY clear at the source level EXACTLY where the subprogram
being called is defined. BUT! the whole idea of dynamic dispatching
is to make absolutely sure that you can NOT tell at the source level
where the subprogram being called is declared. 

There is no clash between dynamic dispatching and the design of Ada, there
is a clash between dynamic dispatching and an insistence on never using
the USE clause, and that is really what Mitch is pointing out.

This really has nothing to do with f(x) vs x.f, since these notations
are equivalent, it has to do with whether or not you want to make
visiility explicit at the source code level. Neither f(x) nor x.f
does this, but package.f(x) does make this explicit (there is no
obvious syntactic analog in the x.f case).

Re: "use" clauses and Ada 95 OOP

[JamesS1889]

In article <dewar.838132930@schonberg>, dewar@cs.nyu.edu (Robert Dewar)
writes:

>People who have learned to be 100% allergic to USE in Ada 83 will find
>some discomfort here, but that's something they bring upon themselves.
>The idea behind disallowing USE clauses is that it is a GOOD THING if
>it is made VERY clear at the source level EXACTLY where the subprogram
>being called is defined. BUT! the whole idea of dynamic dispatching
>is to make absolutely sure that you can NOT tell at the source level
>where the subprogram being called is declared. 
>
>There is no clash between dynamic dispatching and the design of Ada,
there
>is a clash between dynamic dispatching and an insistence on never using
>the USE clause, and that is really what Mitch is pointing out.

Not to mention that without the USE clause, the visibility you get is
misleading.  Yep, Robert, I do believe you "have it surrounded".

Just out of curiosity, though.  Somebody said that WG9 considered making
all operators obsolete (addressing a slightly different issue).  I was
wondering if WG9 considered do what I misunderstood Robert Eachus to be
implying, namely, make "use type" apply also to primitive subprograms of a
tagged type?

James Squire                                      
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com
Opinions expressed here are my own and NOT my company's
"Only one Earth Captain has ever survived battle with a Minbari fleet.  He
is behind me.
You are in front of me.  If you value your lives, be somewhere else!"
           -- Delenn, "Severed Dreams"

Re: "use" clauses and Ada 95 OOP

[Robert A Duff]

In article <4t7vet$ot8@newsbf02.news.aol.com>,
JamesS1889 <jamess1889@aol.com> wrote:
>Not to mention that without the USE clause, the visibility you get is
>misleading.  Yep, Robert, I do believe you "have it surrounded".

Not sure what you mean, there.  Normally, when dispatching, you have NO
visibility on what you're calling, whether or not you use use.  So,
either way, a programmer who wants to dispatch has to understand that
the thing being called has nothing whatsoever to do with what is
visible.

>Just out of curiosity, though.  Somebody said that WG9 considered making
>all operators obsolete (addressing a slightly different issue).

Obsolete?  Heh?

I think I said that the MRT proposed that primitive operators should be
directly visible by default.  WG9 didn't like that, partly because of
upward compatibility concerns.  So we invented "use type" as a
compromise.

It's kind of hard to explain to a beginner why:

    while X /= null loop ...

doesn't work, because "/=" is not directly visible.  But null is visible
everywhere.  Weird.  OK, it has to do with the fact that "/=" can be
defined by the user (well, "=" can, and then you get "/=" for free).
The beginner reasonably says, "But I *never* want to redefine
operators."

>...  I was
>wondering if WG9 considered do what I misunderstood Robert Eachus to be
>implying, namely, make "use type" apply also to primitive subprograms of a
>tagged type?

No.  As far as I know, nobody ever proposed that.  Anyway, that's pretty
close to what a plain old use-package clause does.

- Bob

Re: "use" clauses and Ada 95 OOP

[JamesS1889]

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
>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.  I believe Mitch was speaking NOT of the value
of X but of X as an object, and I believe he was speaking of func as "any
function".  At least that is what I took it as.

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.

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?

James Squire                                      
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com
Opinions expressed here are my own and NOT my company's
"Only one Earth Captain has ever survived battle with a Minbari fleet.  He
is behind me.
You are in front of me.  If you value your lives, be somewhere else!"
           -- Delenn, "Severed Dreams"

Re: "use" clauses and Ada 95 OOP

[JamesS1889]

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
>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.  I believe Mitch was speaking NOT of the value
of X but of X as an object, and I believe he was speaking of func as "any
function".  At least that is what I took it as.

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.

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?

James Squire                                      
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com
Opinions expressed here are my own and NOT my company's
"Only one Earth Captain has ever survived battle with a Minbari fleet.  He
is behind me.
You are in front of me.  If you value your lives, be somewhere else!"
           -- Delenn, "Severed Dreams"

Re: "use" clauses and Ada 95 OOP

[Laurent Guerby]

Mitch> [...]
Mitch> But my point is that a naive Ada 95 reader might think that the
Mitch> call
  
Mitch>     pkg1.func(x)

Mitch> calls the code that is in the body of pkg1.  The syntax in fact
Mitch> implies that strongly.  [...]

   This notation implies that the specification is in pkg1, and the
specification is the important thing, since it's here I'll find the
documentation (no need to look at the body ;-).

   And for dispatching calls, finding the body can be done only at
run-time most of the time. If surprising things can happen, better
document it at the calling point.


-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: "use" clauses and Ada 95 OOP

[Robert A Duff]

In article <ws9spajgc6m.fsf@schonberg.cs.nyu.edu>,
Laurent Guerby <guerby@gnat.com> wrote:
>Mitch>     pkg1.func(x)
>
>Mitch> calls the code that is in the body of pkg1.  The syntax in fact
>Mitch> implies that strongly.  [...]
>
>   This notation implies that the specification is in pkg1, and the
>specification is the important thing, since it's here I'll find the
>documentation (no need to look at the body ;-).

Well said.

- Bob

Re: "use" clauses and Ada 95 OOP

[Jon S Anthony]

In article <ws9spajgc6m.fsf@schonberg.cs.nyu.edu> guerby@gnat.com (Laurent Guerby) writes:

> Mitch>     pkg1.func(x)
> 
> Mitch> calls the code that is in the body of pkg1.  The syntax in fact
> Mitch> implies that strongly.  [...]
> 
>    This notation implies that the specification is in pkg1, and the
> specification is the important thing, since it's here I'll find the
> documentation (no need to look at the body ;-).

Yes, that's what it strictly implies (from the rules), but it is not
hard to understand the point of view (perhaps of a "newcomer") that
the visual cue strongly suggests the call is to the func declared in
pkg1.  I don't have a problem with the notation and do not see it that
way.  Many others "in the know" don't either.

Actually, if anything is a source of potential confusion in this
respect, it is the parameter x.  If it is declared "far enough" away
from the call site and you don't annotate the call with something like
"-- Dispatch to proper func" or use an explicit 'Class conversion, it
could be misleading for a casual read.  This is true irrespective of
using a qualified name (well, unless you use the abstract approach I
mentioned in a previous post).

For example, does pkg1.func(x) dispatch or is it bound to pkg1.func?
Depends on how x is declared (or whether pkg1 contains the abstract
root and operations, which would tell you the call must be dispatching).

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

617.484.3383
jsa@organon.com

Re: "use" clauses and Ada 95 OOP

[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

Re: "use" clauses and Ada 95 OOP

[Jon S Anthony]

In article <31EF9D30.7A0@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> writes:

> Mitch Gart wrote:
>...
> > To me the C++/Java syntax
> >
> >     x.func
> >
> > seems clearer than the Ada syntax in this case because what is being
> > called is the function that is associated with X at runtime, rather than
> > the function that comes from a given package.
> 
> Indeed, that is a drawback that was mentioned in our group by someone
> who is familiar with C++.  I can't argue with it at all.

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
necessarily be the one defined in the class of which X was a declared
instance).  Seems pretty much like the exact same issue.

/Jon

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

617.484.3383
jsa@organon.com

Re: "use" clauses and Ada 95 OOP

[Robert I. Eachus]

In article <Dup54L.2q2.0.-s@inmet.camb.inmet.com> mg@asp.camb.inmet.com (Mitch Gart) writes:

  > It seems to me that this notation is misleading because a reader might
  > think that the function in pkg1 will be executed.  

  > Therefore with tagged types I have adopted the style of always using
  > "use" clauses and writing the call

  >     func(x);

  > in the source code.  This seems less misleading to me.  I never used to
  > use "use" clauses in Ada 83 but I now use them a lot in Ada 95 when 
  > calling dispatching operations.

  > Have other people adopted this style?  Comments?  People who have written
  > coding standards which say "don't use 'use' clauses", do you think this
  > rule is still a good idea with Ada 95 dispatching?

    My rule is to always "use type" dispatching types.  The names you
no longer have to qualify are the ones where the qualification would
be misleading.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: "use" clauses and Ada 95 OOP

[JamesS1889]

In article <Duwu74.L3n@world.std.com>, bobduff@world.std.com (Robert A
Duff) writes:

>Your earlier impression was correct.  "Use type" only works for
>(primitive) operators, like "&", "+", etc.  It does not work for
>operations called "func" or whatever.

Then I'm confused about something.  See below.  Meanwhile...

>An earlier version of Ada 9X proposed to make primitive operators
>automatically visible -- sort of as if "use type" were always there by
>magic.  However, this would have been upward incompatible in some rare
>cases.  The "use type" feature was invented as a compromise.

I'm amazed they did think of it - good for them.  But that's not what I
was talking about.

In article <JSA.96Jul22154610@alexandria>, jsa@alexandria (Jon S Anthony)
writes:

>A use_type clause only gives "direct" visibility to primitive _operators_
>of the type: RM 8.4(8).

OK.  So then would someone tell me what the following meant:

In article <EACHUS.96Jul19102232@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) writes:

>    My rule is to always "use type" dispatching types.  The names you
>no longer have to qualify are the ones where the qualification would
>be misleading.

Did Robert mean what I thought he meant (in which case you are saying he
is wrong), or did he mean something else?

Enquiring minds want to know...

James Squire                                      
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com
Opinions expressed here are my own and NOT my company's
"Only one Earth Captain has ever survived battle with a Minbari fleet.  He
is behind me.
You are in front of me.  If you value your lives, be somewhere else!"
           -- Delenn, "Severed Dreams"

Re: "use" clauses and Ada 95 OOP

[Robert Dewar]

James Squire asks

"OK.  So then would someone tell me what the following meant:

In article <EACHUS.96Jul19102232@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) writes:

>    My rule is to always "use type" dispatching types.  The names you
>no longer have to qualify are the ones where the qualification would
>be misleading."


What it meant was that Robert Eachus never tried following his own rule :-)
As is hopefully clear from followup posts, this rule cannot work.

Re: "use" clauses and Ada 95 OOP

[Robert I. Eachus]

   In article <EACHUS.96Jul19102232@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:

   >    My rule is to always "use type" dispatching types.  The names you
   > no longer have to qualify are the ones where the qualification would
   > be misleading."

In article <dewar.838151887@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

   > What it meant was that Robert Eachus never tried following his
   > own rule :-) As is hopefully clear from followup posts, this rule
   > cannot work.

    No, if you have seen MY followup post, it should be obvious that
this rule is not for everyone.  It only works for those user defined
operations with names in 4.5.  I am right now in the process of
converting the ADAR multiprecision arithmetic packages to Ada 95.  For
some reason, it makes sense to make the various types members of the
same class (it would be nice if I could make them scalar numeric
types, but I digress).

    For some reason all of the predefined operations on those types,
other than conversions, have names like "+", "-", ">",...  If you look
at the (Ada 83) Dates package I posted to the Team Ada list last week,
you will see the same thing.  (I'll release the package generally
later this week or early next week.)  Almost all the operations fall
into two categories, conversions between types, and Ada predefined
operators, in this case mostly comparisons.  Looking at the Ada 95
Annexes convinces me that I am not the only one who programs this way.

    So I stand by my advice.  In other areas it may not be as
useful, but that is a subject for Ada 0Y.



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: "use" clauses and Ada 95 OOP

[Robert I. Eachus]

   In article <31F170FC.672C@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> wrote:

   > Very interesting!  Let me see if I'm reading you right:

   > 1.  func would have to be a primitive operation in order to be a
   > dispatching call.  Right?

   > 2.  Therefore, func would be covered by the "use type" clause on
   > <type_of_x>, right?

   > I liked the idea of "use type" when I thought it only referred to
   > implicit operations like "&", "+", "=" (operations that I wish the Ada
   > designers had made a part of the language proper so we wouldn't have any
   > need for the use clause).  Now that it seems "use type" applies to all
   > primitive operations (some of which are user-written, like "Handle",

In article <JSA.96Jul22154610@alexandria> jsa@alexandria (Jon S Anthony) writes:

   > A use_type clause only gives "direct" visibility to primitive _operators_
   > of the type: RM 8.4(8).

   The reality is somewhere in the middle.

   RM 3.2.3(8): "A primitive subprogram whose designator is an
operator_symbol is called a _primitive_operator_."

   RM 3.2.3(1):  "The _primitive_operations of a type are the
predefined operations of the type, plus any user-defined primitive
subprograms."

   So yes, this "trick" only works for 21 specific names.  But there
are lots of cases where using these symbols (including and, or, xor,
"&", mod, rem, abs, not) make lots of sense for abstract data types.

   For example, take a set abstraction.  All but two operations
(Is_Empty and Empty) are best defined as Ada operators.  (Note also
that function "+"(L: Set; R: Element) return Set; can be a primitive
operator of either Set or Element depending on where it is defined.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: "use" clauses and Ada 95 OOP

[JamesS1889]

In article <JSA.96Jul23220309@alexandria>, jsa@alexandria (Jon S Anthony)
writes:

>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.

And I actually don't know as much as I should about dispatching in C++. 
You're right, it probably doesn't matter.  I was actually talking about
syntactic analogy.  Semantically, you are right.

>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.

Agreed.

>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):

Maybe so.  It's under consideration ;-)

James Squire                                      
mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com
Opinions expressed here are my own and NOT my company's
"Only one Earth Captain has ever survived battle with a Minbari fleet.  He
is behind me.
You are in front of me.  If you value your lives, be somewhere else!"
           -- Delenn, "Severed Dreams"

Re: "use" clauses and Ada 95 OOP

[Jon S Anthony]

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

> In article <JSA.96Jul22154610@alexandria>, jsa@alexandria (Jon S Anthony)
> writes:
> 
> >A use_type clause only gives "direct" visibility to primitive _operators_
> >of the type: RM 8.4(8).
> 
> OK.  So then would someone tell me what the following meant:
> 
> In article <EACHUS.96Jul19102232@spectre.mitre.org>,
> eachus@spectre.mitre.org (Robert I. Eachus) writes:
> 
> >    My rule is to always "use type" dispatching types.  The names you
> >no longer have to qualify are the ones where the qualification would
> >be misleading.
> 
> Did Robert mean what I thought he meant (in which case you are saying he
> is wrong), or did he mean something else?

When I read that, I thought he misspoke, because if literally taken it
would mean either a) he's confused/wrong or b) only defines "operator"
primitive operations for his tagged types.  Neither of which seem very
likely...

> "Only one Earth Captain has ever survived battle with a Minbari
> fleet.  He is behind me.  You are in front of me.  If you value your
> lives, be somewhere else!"  -- Delenn, "Severed Dreams"

One of the best scenes to ever hit the airways (or anything else for that
matter!)


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

617.484.3383
jsa@organon.com

Re: "use" clauses and Ada 95 OOP

[James A. Squire]

Robert I. Eachus wrote:
>
> In article <Dup54L.2q2.0.-s@inmet.camb.inmet.com> mg@asp.camb.inmet.com (Mitch
> Gart) writes:
>
>   > It seems to me that this notation is misleading because a reader might
>   > think that the function in pkg1 will be executed.
>
>   > Therefore with tagged types I have adopted the style of always using
>   > "use" clauses and writing the call
>
>   >     func(x);
>
>   > in the source code.  This seems less misleading to me.  I never used to
>   > use "use" clauses in Ada 83 but I now use them a lot in Ada 95 when
>   > calling dispatching operations.
>
>   > Have other people adopted this style?  Comments?  People who have written
>   > coding standards which say "don't use 'use' clauses", do you think this
>   > rule is still a good idea with Ada 95 dispatching?
>
>     My rule is to always "use type" dispatching types.  The names you
> no longer have to qualify are the ones where the qualification would
> be misleading.

Very interesting!  Let me see if I'm reading you right:

1.  func would have to be a primitive operation in order to be a
dispatching call.  Right?

2.  Therefore, func would be covered by the "use type" clause on
<type_of_x>, right?

I liked the idea of "use type" when I thought it only referred to
implicit operations like "&", "+", "=" (operations that I wish the Ada
designers had made a part of the language proper so we wouldn't have any
need for the use clause).  Now that it seems "use type" applies to all
primitive operations (some of which are user-written, like "Handle",
etc.), I'm not so sure.  For example, I would have a coding style rule
that says that all dispatching calls must be properly annotated so that
a maintainer knows what is going on.  How does a code reviewer enforce
such a rule if the developer forgot to annotate it?  How does he tell
that the call is a dispatching call in a normal piece of complex
application code (i.e., this is no "Hello World" we're talking about
here)?
--
James Squire                             mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com/
Opinions expressed here are my own and NOT my company's
"Commander, it's not your decision. We're going. What are you going to
do,
    shoot us down?"
'If that's what's required to protect this station, yes.'
"Excuse me?"
        -- Captain Pierce and Sinclair, "A Voice in the Wilderness II"

Re: "use" clauses and Ada 95 OOP

[Robert A Duff]

In article <31F170FC.672C@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>I liked the idea of "use type" when I thought it only referred to
>implicit operations like "&", "+", "=" (operations that I wish the Ada
>designers had made a part of the language proper so we wouldn't have any
>need for the use clause).

Your earlier impression was correct.  "Use type" only works for
(primitive) operators, like "&", "+", etc.  It does not work for
operations called "func" or whatever.

An earlier version of Ada 9X proposed to make primitive operators
automatically visible -- sort of as if "use type" were always there by
magic.  However, this would have been upward incompatible in some rare
cases.  The "use type" feature was invented as a compromise.

- Bob

Re: "use" clauses and Ada 95 OOP

[Jon S Anthony]

In article <31F170FC.672C@csehp3.mdc.com> "James A. Squire" <m193884@CSEHP3.MDC.COM> writes:

> Robert I. Eachus wrote:
> >
> > In article <Dup54L.2q2.0.-s@inmet.camb.inmet.com> mg@asp.camb.inmet.com (Mitch
> >     My rule is to always "use type" dispatching types.  The names you
> > no longer have to qualify are the ones where the qualification would
> > be misleading.
> 
> Very interesting!  Let me see if I'm reading you right:
> 
> 1.  func would have to be a primitive operation in order to be a
> dispatching call.  Right?
> 
> 2.  Therefore, func would be covered by the "use type" clause on
> <type_of_x>, right?
> 
> I liked the idea of "use type" when I thought it only referred to
> implicit operations like "&", "+", "=" (operations that I wish the Ada
> designers had made a part of the language proper so we wouldn't have any
> need for the use clause).  Now that it seems "use type" applies to all
> primitive operations (some of which are user-written, like "Handle",

A use_type clause only gives "direct" visibility to primitive _operators_
of the type: RM 8.4(8).

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

617.484.3383
jsa@organon.com

Re: "use" clauses and Ada 95 OOP

[Jon S Anthony]

In article <SCHMID.96Jul22104727@alta.ide.com> schmid@alta.ide.com (Stephen Schmid) writes:

[good stuff on why x.func has basically the same "problem" as that pointed
 out for Ada func(x) ... snipped]

> the use clause.  With the use clause, the reader has no clue as to
> which function is being called without checking the context clauses, and
> there is greater opportunity for error.  You are giving the reader _less_
> information, which cannot be helpful.  Including the package name gives
> the reader a starting point to determine what functions may be called at
> runtime.  In a language with run-time dispatching, that is the most that
> you can do.  

Part of the issue here revolves around the fact that one of the
features of dynamic polymorphism is that you not only don't know what
will be called you are supposed to _like_ this aspect.

One possible "compromise" that some people advocate is to always
provide an "abstract base" for any new extension introducing new
operations (not overrides).  Then you always make a dispathing call on
such operations via the abstract version (including the package name).
The idea is that a) you will show which "sort" of operation is being
called (by the qualified name), and b) you will know that it isn't the
exact one named (which is abstract) so that it won't "look odd" or
whatever.  Just a thought...

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

617.484.3383
jsa@organon.com