* Re: "use" clauses and Ada 95 OOP
1996-07-22 0:00 ` Stephen Schmid
@ 1996-07-23 0:00 ` Laurent Guerby
1996-07-23 0:00 ` Robert A Duff
1996-07-23 0:00 ` JamesS1889
` (4 subsequent siblings)
5 siblings, 1 reply; 29+ messages in thread
From: Laurent Guerby @ 1996-07-23 0:00 UTC (permalink / raw)
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)."
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-23 0:00 ` Laurent Guerby
@ 1996-07-23 0:00 ` Robert A Duff
0 siblings, 0 replies; 29+ messages in thread
From: Robert A Duff @ 1996-07-23 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-22 0:00 ` Stephen Schmid
1996-07-23 0:00 ` Laurent Guerby
@ 1996-07-23 0:00 ` JamesS1889
1996-07-23 0:00 ` JamesS1889
` (3 subsequent siblings)
5 siblings, 0 replies; 29+ messages in thread
From: JamesS1889 @ 1996-07-23 0:00 UTC (permalink / raw)
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"
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-22 0:00 ` Stephen Schmid
1996-07-23 0:00 ` Laurent Guerby
1996-07-23 0:00 ` JamesS1889
@ 1996-07-23 0:00 ` JamesS1889
1996-07-23 0:00 ` Mitch Gart
` (2 subsequent siblings)
5 siblings, 0 replies; 29+ messages in thread
From: JamesS1889 @ 1996-07-23 0:00 UTC (permalink / raw)
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"
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-22 0:00 ` Stephen Schmid
` (2 preceding siblings ...)
1996-07-23 0:00 ` JamesS1889
@ 1996-07-23 0:00 ` Mitch Gart
1996-07-23 0:00 ` Kevin J. Weise
` (3 more replies)
1996-07-24 0:00 ` Jon S Anthony
1996-07-24 0:00 ` Jon S Anthony
5 siblings, 4 replies; 29+ messages in thread
From: Mitch Gart @ 1996-07-23 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-23 0:00 ` Mitch Gart
@ 1996-07-23 0:00 ` Kevin J. Weise
1996-07-23 0:00 ` JamesS1889
1996-07-23 0:00 ` Kevin J. Weise
` (2 subsequent siblings)
3 siblings, 1 reply; 29+ messages in thread
From: Kevin J. Weise @ 1996-07-23 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-23 0:00 ` Kevin J. Weise
@ 1996-07-23 0:00 ` JamesS1889
0 siblings, 0 replies; 29+ messages in thread
From: JamesS1889 @ 1996-07-23 0:00 UTC (permalink / raw)
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"
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-23 0:00 ` Mitch Gart
1996-07-23 0:00 ` Kevin J. Weise
@ 1996-07-23 0:00 ` Kevin J. Weise
1996-07-23 0:00 ` Robert A Duff
1996-07-23 0:00 ` Robert Dewar
3 siblings, 0 replies; 29+ messages in thread
From: Kevin J. Weise @ 1996-07-23 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-23 0:00 ` Mitch Gart
1996-07-23 0:00 ` Kevin J. Weise
1996-07-23 0:00 ` Kevin J. Weise
@ 1996-07-23 0:00 ` Robert A Duff
1996-07-23 0:00 ` Robert Dewar
3 siblings, 0 replies; 29+ messages in thread
From: Robert A Duff @ 1996-07-23 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-23 0:00 ` Mitch Gart
` (2 preceding siblings ...)
1996-07-23 0:00 ` Robert A Duff
@ 1996-07-23 0:00 ` Robert Dewar
1996-07-25 0:00 ` JamesS1889
3 siblings, 1 reply; 29+ messages in thread
From: Robert Dewar @ 1996-07-23 0:00 UTC (permalink / raw)
"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).
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-23 0:00 ` Robert Dewar
@ 1996-07-25 0:00 ` JamesS1889
1996-07-26 0:00 ` Robert A Duff
0 siblings, 1 reply; 29+ messages in thread
From: JamesS1889 @ 1996-07-25 0:00 UTC (permalink / raw)
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"
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-25 0:00 ` JamesS1889
@ 1996-07-26 0:00 ` Robert A Duff
0 siblings, 0 replies; 29+ messages in thread
From: Robert A Duff @ 1996-07-26 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-22 0:00 ` Stephen Schmid
` (3 preceding siblings ...)
1996-07-23 0:00 ` Mitch Gart
@ 1996-07-24 0:00 ` Jon S Anthony
1996-07-24 0:00 ` Jon S Anthony
5 siblings, 0 replies; 29+ messages in thread
From: Jon S Anthony @ 1996-07-24 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: "use" clauses and Ada 95 OOP
1996-07-22 0:00 ` Stephen Schmid
` (4 preceding siblings ...)
1996-07-24 0:00 ` Jon S Anthony
@ 1996-07-24 0:00 ` Jon S Anthony
5 siblings, 0 replies; 29+ messages in thread
From: Jon S Anthony @ 1996-07-24 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 29+ messages in thread