comp.lang.ada
 help / color / mirror / Atom feed
* Invocation of Shadowed Implementations in Ada 95
@ 1996-09-04  0:00 Larry Kilgallen
  1996-09-05  0:00 ` Jon S Anthony
  0 siblings, 1 reply; 3+ messages in thread
From: Larry Kilgallen @ 1996-09-04  0:00 UTC (permalink / raw)



I have read in "Object-Oriented Programming with Ada 9X",
Copyright 1993 by S. Barbey, M. Kempe, and A. Strohmeier
a description of "invocation of shadowed implementations".

>      procedure Display (M: Man) is
>        begin
>          Display (Human (M));  -- invocation of the shadowed implementation
>          Put (", male");
>          if Is_Bearded (M) then
>            Put (" is bearded");
>          end if;
>        end Display;

Is this really the way this is to be done ?

Although it is in the spirit of Ada syntax, it seems to me inferior
to the Macintosh Pascal approach of:

	inherited Display (M);

in that the Ada example requires revisiting many more procedures
if the type hierarchy is changed (unlikely for the particular
example given, but more likely in other situations).

Larry Kilgallen




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Invocation of Shadowed Implementations in Ada 95
  1996-09-04  0:00 Invocation of Shadowed Implementations in Ada 95 Larry Kilgallen
@ 1996-09-05  0:00 ` Jon S Anthony
  1996-09-06  0:00   ` Larry Kilgallen
  0 siblings, 1 reply; 3+ messages in thread
From: Jon S Anthony @ 1996-09-05  0:00 UTC (permalink / raw)



In article <1996Sep4.163433.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> Although it is in the spirit of Ada syntax, it seems to me inferior
> to the Macintosh Pascal approach of:
> 
> 	inherited Display (M);

Which gives no idea as to what is really going on - must look elsewhere
to see what is inherited.  Is it direct ancestor or remote?

> in that the Ada example requires revisiting many more procedures
> if the type hierarchy is changed (unlikely for the particular
> example given, but more likely in other situations).

Thereby preventing or at least reducing unexpected spurious behavior that
would have been very expensive to track down...

/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] 3+ messages in thread

* Re: Invocation of Shadowed Implementations in Ada 95
  1996-09-05  0:00 ` Jon S Anthony
@ 1996-09-06  0:00   ` Larry Kilgallen
  0 siblings, 0 replies; 3+ messages in thread
From: Larry Kilgallen @ 1996-09-06  0:00 UTC (permalink / raw)



In article <JSA.96Sep5152213@alexandria>, jsa@alexandria (Jon S Anthony) writes:
> In article <1996Sep4.163433.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> 
>> Although it is in the spirit of Ada syntax, it seems to me inferior
>> to the Macintosh Pascal approach of:
>> 
>> 	inherited Display (M);
> 
> Which gives no idea as to what is really going on - must look elsewhere
> to see what is inherited.  Is it direct ancestor or remote?

My direct ancestor, which may in turn, call on its direct
ancestor.  To skip generations seems to me as dangerous as
guessing how to handle conflicts in multiple inheritance.
I want to do whatever my ancestors do, plus my own operations.
Presuming my ancestors are properly constructed, I will not alter
their internal actions (even if Ada let me).  The prime concept of
inheritance seems to me that I do not have to know the detailed
behaviour of my ancestors.  If that were not the case, we could
do it all with subroutines.  Or Macros (just to be rude in C.L.A. :-).

I suppose one way to achieve what I want is to use some qualifier
which indicates "my direct ancestor type", but I have the feeling it
is going to be more keystrokes than I had wanted.  Can someone say if
there is a way to specify "direct ancestor of my type" in Ada 95 ?

>> in that the Ada example requires revisiting many more procedures
>> if the type hierarchy is changed (unlikely for the particular
>> example given, but more likely in other situations).
> 
> Thereby preventing or at least reducing unexpected spurious behavior that
> would have been very expensive to track down...

I would hope for isolation of functions such that maintaining one
tagged type does not require revisiting all children.  Otherwise,
we should be using just one package for any program.

Larry Kilgallen




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1996-09-06  0:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-09-04  0:00 Invocation of Shadowed Implementations in Ada 95 Larry Kilgallen
1996-09-05  0:00 ` Jon S Anthony
1996-09-06  0:00   ` Larry Kilgallen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox