maintenance of overriding subprograms

maintenance of overriding subprograms

[Stephen Leake]

The discussion of maintaining separate spec and implementation reminded
me of a potential maintenance problem with overriding subprograms of
derived types. Suppose we have:

   package Root is
      type Root_Type is tagged private;

      procedure Create (Item : in out Root_Type);
   private
      type Root_Type is tagged record
         Count : Integer;
      end record;
   end Root;

   package body Root is
      procedure Create (Item : in out Root_Type)
      is begin
         Item.Count := 0;
      end Create;
   end Root;

   package Derived is
      type Derived_Type is new Root.Root_Type with private;

      -- override Create (Root_Type)
      procedure Create (Item : in out Derived_Type);
   private
      type Derived_Type is new Root.Root_Type with record
         Leaves : Integer;
      end record;
   end Derived;

   package body Derived is
      procedure Create (Item : in out Derived_Type)
      is begin
         Root.Create (Root.Root_Type (Item));
         Item.Leaves := 0;
      end Create;
   end Derived;

Now suppose that in maintenance we add a parameter to Root.Create:

  procedure Create (Item : in out Root_Type; Max : in Integer := 0);

When we compile, the compiler tells us that the package body of Root
does not have a corresponding body for Create. However, it does not tell
us that Derived.Create no longer overrides Root.Create; Derived.Create
silently changes from an overriding subprogram to a "normal" subprogram.

To solve this, perhaps we could add a pragma:

pragma Confirm_Override ({subprogram_name});

which would generate a compile-time error if {subprogram_name} does not
override a root type subprogram. In Ada 200x, we could use the keyword
"new" for this:

new procedure Create (...);

which would have the same effect.

Any comments?
-- 
- Stephe

Re: maintenance of overriding subprograms

[John G. Volan]

Tom Moran wrote:
> 
> A related error, not, unfortunately, solved by that syntax occurs when a
> maintainer erroneously believes some parameter to have a default, and
> accordingly removes or comments it out in a call, eg
>   package Basic is
>     type Object_Type is tagged ...
>     procedure Create_Object(X : Object_Type;
>         Name : in String; Size, Position : in Rectangles);
> ...
>   package Fancy is
>     type Fancy_Object_Type is new Basic.Object_Type with ...
>     procedure Create_Object(X : Fancy_Object_Type;
>         Name : in String; Size, Position : in Rectangles;
>         Title : in String);
> ...
> A call
>   Create_Object(X -- X is a Fancy_Object
>      "It's name", The_Size, The_Position, "");
> is erroneously changed to
>   Create_Object(X -- X is a Fancy_Object
>      "It's name", The_Size, The_Position);
> under the misapprehension that Title defaults to the null string.  But
> in fact this has changed from a call on Fancy.Create to an inherited
> call on Basic.Create  Manual proofreading of the code is fairly likely
> to miss the error, but what's especially insidious is that the behavior
> is probably quite similar, so the fact there is a problem may not show
> up for some time.

    package Basic is
    
You can avoid this sort of thing by adopting the following practices:

(1)  Give controlling subprogram parameters names that reflect their
level of abstraction. Don't use an "inherited" identifier.  e.g.:

  package Basic is
    type Basic_Object_Type is tagged ...
    procedure Create
      (Basic_Object    : in out Basic_Object_Type; 
        Name           : in     String;
        Size, Position : in     Rectangle_Type);
...
  package Fancy is
    type Fancy_Object_Type is new Basic.Basic_Object_Type with ...
    procedure Create
      (Fancy_Object   : in out Fancy_Object_Type; 
       Name           : in     String;
       Size, Position : in     Rectangle_Type;
       Title          : in     String);
...

(2) Use named parameter association syntax religiously, e.g.:

  Fancy.Create 
    (Fancy_Object => Your_Fancy_Object -- _obviously_ a Fancy_Object
     Name         => "It's name", 
     Size         => The_Size,
     Position     => The_Position,
     Title        => "");

If you then try to change it to:

  Fancy.Create 
    (Fancy_Object => Your_Fancy_Object -- _obviously_ a Fancy_Object
     Name         => "It's name", 
     Size         => The_Size,
     Position     => The_Position);

then you get a compilation error.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: maintenance of overriding subprograms

[Robert Dewar]

<<Clearly this error mode can occur without OO programming, but it's
likely to become substantially more common with heavy use of derived
types.>>

What would be more interesting is to hear from people who have actually
found this to be a problem ... often language experts sit around imagining
things that do not really happen, so the most useful input on errors is
input from people who actually run into them.

Certainly in the case of GNAT, both the compile time and runtime error handling
and in particular the choice of warnings that are needed are very much
conditioned by user experience in running into problems.

All the problems Tom Moran mentions can probably be significantly
ameliorated by some additional warning messages, but I would hesitate
to implement such warnings unless I heard from at least one user who
said they had run into trouble. So far, among the thousands of GNAT
users over several years of use, many of whom are not shy about making
suggestions for new messages and warnings :-) no one has commented that
this was a trouble spot.

Re: maintenance of overriding subprograms

[Robert A Duff]

In article <dewar.873631018@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
><<Clearly this error mode can occur without OO programming, but it's
>likely to become substantially more common with heavy use of derived
>types.>>
>
>What would be more interesting is to hear from people who have actually
>found this to be a problem ... often language experts sit around imagining
>things that do not really happen, so the most useful input on errors is
>input from people who actually run into them.

No, I don't think that works.  People who run into errors fix those
errors as best they can -- they don't (usually) think about some amazing
language change or compiler fix/warning or development technique that
could have prevented the problem in the first place.

I think it's quite right for "language experts" to imagine things that
might happen, and try to prevent them.

Think of all the C and Smalltalk programmers who have never encountered
a type error.  They encounter seg faults, and does-not-understand
messages, respectively, but they don't call them type errors, so they
don't tend to think, "gee, if only the compiler had ...".

>Certainly in the case of GNAT, both the compile time and runtime error handling
>and in particular the choice of warnings that are needed are very much
>conditioned by user experience in running into problems.
>
>All the problems Tom Moran mentions can probably be significantly
>ameliorated by some additional warning messages, but I would hesitate
>to implement such warnings unless I heard from at least one user who
>said they had run into trouble. So far, among the thousands of GNAT
>users over several years of use, many of whom are not shy about making
>suggestions for new messages and warnings :-) no one has commented that
>this was a trouble spot.

That means nothing.  Anyone who hit this bug would naturally (and
correctly) assume it was their own fault, and fix it, and then forget
it.

In any case, warnings are no good (IMHO) if they warn about OK things.
In this particular case, I can't see how to warn about the bad cases
without also warning about the good.

- Bob

Re: maintenance of overriding subprograms

[Dan Johnston D.B.]

In <dewar.873631018@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

><<Clearly this error mode can occur without OO programming, but it's
>likely to become substantially more common with heavy use of derived
>types.>>

>What would be more interesting is to hear from people who have actually
>found this to be a problem ... often language experts sit around imagining
>things that do not really happen, so the most useful input on errors is
>input from people who actually run into them.

>Certainly in the case of GNAT, both the compile time and runtime error handling
>and in particular the choice of warnings that are needed are very much
>conditioned by user experience in running into problems.

I have certainly been caught by misspelling a routine intended to override
another.  This would not be a problem if the two cases were syntactically
distinguished.
To be more specific, I spelt "Initialize" as "Initialise" which is the
correct spelling of this word in Australian English.  ( I know the Americans
spell it with "ize", but am not sure how it is spelt by English people.)
Anyway, this attempted overriding of the routine in Ada.Finalization resulted
in a constraint error because of the failure to initialise the structure,
rather than a compiler error which one would normally expect from misspelling
an identifier.

It is hard to see what an Ada compiler can do about this in the general case
and, one wonders if it is worth the trouble in the specific case. (Are other
programmers so fixed in their ways that they have trouble adapting to
the American spelling? )

Anyway, in my opinion it is a language design fault that overriding routines
are not syntactically distinguished from "new" routines.

        dan.               dan@it.uq.edu.au
                             Dan Johnston, School of Information Technology,
                               University of Queensland, Australia.

Re: maintenance of overriding subprograms

[W. Wesley Groleau x4923]

> I have certainly been caught by misspelling a routine intended to override
> another.  This would not be a problem if the two cases were syntactically
> distinguished.
> To be more specific, I spelt "Initialize" as "Initialise" which is the
> correct spelling of this word in Australian English.  ( I know the Americans
> spell it with "ize", but am not sure how it is spelt by English people.)
> Anyway, this attempted overriding of the routine in Ada.Finalization resulted
> in a constraint error because of the failure to initialise the structure,
> rather than a compiler error which one would normally expect from misspelling
> an identifier.

Workaround (not the ideal, but would help)

for each identifier in a susceptible set
   use "agrep" to look for close but not exact matches.

(agrep = approximate grep.  It is also the basis of a Web tool
called glimpse.  Web search for either should find plenty.)

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: maintenance of overriding subprograms

[Tom Moran]

>What would be more interesting is to hear from people who have actually
>found this to be a problem ... often language experts sit around imagining
>things that do not really happen, so the most useful input on errors is
>input from people who actually run into them.
  I was bit.  I did not imagine it.

Re: maintenance of overriding subprograms

[Robert Dewar]

Dan says

<<To be more specific, I spelt "Initialize" as "Initialise" which is the
correct spelling of this word in Australian English.  ( I know the Americans
spell it with "ize", but am not sure how it is spelt by English people.)
Anyway, this attempted overriding of the routine in Ada.Finalization resulted
in a constraint error because of the failure to initialise the structure,
rather than a compiler error which one would normally expect from misspelling
an identifier.>>


Although there is no one authority for American spelling that is definitive,
the spelling with Z is universal in the US. In England, there is one
authority, the OED, and as we have discussed before in this newsgroup,
the OED ONLY permits the spelling with the Z, and does not recognize
the spelling with an S. 

This is the case, despite the fact that many Englishmen would swear that
British English requires an S. Thus it is not good enough for someone
from Australia to merely claim that this is the standard Australian
English spelling, you need to cite some appropriate authority.

All of which of course is besides the original point, which is that in both
England and Australia, and who knows where else, people do indeed spell
it with an S, and get no initialization (or finalization) as a result,
which can be quite a surprise.

In fact on our list to do with GNAT is always to warn if a primitive
operation is defined on a controlled type with the names Initialise or
Finalise if the profile matches that of the Z-equivalents.

Re: maintenance of overriding subprograms

[Dan Johnston D.B.]

In <dewar.873939443@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Dan says

><<To be more specific, I spelt "Initialize" as "Initialise" which is the
>correct spelling of this word in Australian English.  ( I know the Americans
>spell it with "ize", but am not sure how it is spelt by English people.)
>Anyway, this attempted overriding of the routine in Ada.Finalization resulted
>in a constraint error because of the failure to initialise the structure,
>rather than a compiler error which one would normally expect from misspelling
>an identifier.>>

>Although there is no one authority for American spelling that is definitive,
>the spelling with Z is universal in the US. In England, there is one
>authority, the OED, and as we have discussed before in this newsgroup,
>the OED ONLY permits the spelling with the Z, and does not recognize
>the spelling with an S. 

>This is the case, despite the fact that many Englishmen would swear that
>British English requires an S. Thus it is not good enough for someone
>from Australia to merely claim that this is the standard Australian
>English spelling, you need to cite some appropriate authority.

Pretty irrelevent to the newsgroup, but the Macquarie Dictionary (which I
believe to be the standard Australian dictionary ) has "initialise" 
and doesn't have "initialize".
      ("recognize" which you use above isn't in it either.)

>All of which of course is besides the original point, which is that in both
>England and Australia, and who knows where else, people do indeed spell
>it with an S, and get no initialization (or finalization) as a result,
>which can be quite a surprise.

>In fact on our list to do with GNAT is always to warn if a primitive
>operation is defined on a controlled type with the names Initialise or
>Finalise if the profile matches that of the Z-equivalents.

     Good, I hope not to be caught again, but the "ise" comes so intuitively
that it might.  (After all, I had to put  with Ada.Finalization; at the top
so was aware of the problem.)
Actually "finalize" does make it into the Macquarie dictionary (although
as a somewhat secondary entry):
  finalise ... To put in final form; conclude, settle.  Also, finalize.

  The main point is that not syntactically distinguishing between overriding
declarations and new declarations is prone to undetected errors.

     dan.                 dan@cs.uq.edu.au 

Re: maintenance of overriding subprograms

[Robert Dewar]

<<  The main point is that not syntactically distinguishing between overriding
declarations and new declarations is prone to undetected errors.>>

Yes indeed, the general approach for warnings we were considering is
the following

For a derived type, if you introduce a primitive operation with a name
that is a close misspelling of an inherited primitive operator, and the
inherited primitive operator is nt otherwise overridden, then you give
a warning (and of coruse Initialise with no Initialize would just be a
special case of this check).

Re: maintenance of overriding subprograms

[Richard A. O'Keefe]

This thread is based on initialise/initialize.
I have real trouble with colour/color (I mean, English is French based,
not Spanish based, right? (:-) (:-)).

Something that would be very helpful would be a way to say
"treat these two spellings as identical".

This would also be of use for people whose languages _do_ have an Academy
(which the OED is _not_ for English) and where that Academy from time to
time revises spellings.  I believe German has recently undergone a
revision, the nature and scope of which I don't begin to understand, but
is it not possible that people might have to cope with before/after
spellings for a while?

'rename' _almost_ does the job, but not quite.  In particular, if you
introduce a renaming for a primitive operation, you can't override the
_old_ name by overriding the _new_ name.

Something like this could get out of hand, I'm afraid.
A way of saying "forbid this identifier whenever this other identifier
is in use" would be less prone to abuse.  Point is, whichever it is,
it shouldn't be limited to a handful of built-in words.

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: maintenance of overriding subprograms

[Samuel Mize]

Richard A. O'Keefe wrote:
> A way of saying "forbid this identifier whenever this other identifier
> is in use" would be less prone to abuse.  Point is, whichever it is,
> it shouldn't be limited to a handful of built-in words.

Certainly there could be a separate tool that checks for this,
if you want it checked in your environment.  At the simplest
level, set up a list of "forbidden" words and automate a grep
for them.  A more Ada-aware tool could be built using the
output of a cross-reference tool or a commercial front-end
parser.

I certainly don't think it belongs in the language definition!

Sam Mize

Re: maintenance of overriding subprograms

[Shmuel (Seymour J.) Metz]

Richard A. O'Keefe wrote:
> 
> This thread is based on initialise/initialize.
> I have real trouble with colour/color (I mean, English is French based,
> not Spanish based, right? (:-) (:-)).

No, English is based on a whole string of invasions, and the Norman
Conquest 
was only the most recent. In addition to the languages that fed into
English
via invasions, there was the usual influx of words from the classical
languages. I'd say that English is more of a Germanic language than a
Romance language, but there are many othe strands in it as well.
 
> This would also be of use for people whose languages _do_ have an Academy

Well, in the examples I'm familiar with, the Academy decrees but the
people
continue talking and writing as they please. Neither the French nor the 
Hebrew language academies have been very successful in changing the 
vernacular.
 
-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: maintenance of overriding subprograms

[John G. Volan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]


Shmuel (Seymour J.) Metz wrote:
> 
> Richard A. O'Keefe wrote:
> >
> > This thread is based on initialise/initialize.
> > I have real trouble with colour/color (I mean, English is French based,
> > not Spanish based, right? (:-) (:-)).
> 
> No, English is based on a whole string of invasions, and the Norman
> Conquest was only the most recent. 

The most recent invasion _into_ Great Britain perhaps, but surely not
the most recent _invasion_ to have influenced the English language.  One
must consider also the invasions of English _from_ Great Britain to
other parts of the globe.  For instance, from its invasion of North
America, English has gained Amerindian words such as "okay", "squash",
"potato", "tomato", "maize", "chocolate", etc.  Then there are words
borrowed from the original Indians, due to Britain�s invasion of their
subcontinent, words such as: "khaki", "nabob", "pundit", "thug", etc.

Then there is the more recent invasion of Britain into North American,
for which we can thank such worthy additions as "groovy", "fab", and
"beatlemania". :-)

-- 
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");

Re: maintenance of overriding subprograms

[Shmuel (Seymour J.) Metz]

John G. Volan wrote:
> 
> Shmuel (Seymour J.) Metz wrote:
> >
> > Richard A. O'Keefe wrote:
> > >
> > > This thread is based on initialise/initialize.
> > > I have real trouble with colour/color (I mean, English is French based,
> > > not Spanish based, right? (:-) (:-)).
> >
> > No, English is based on a whole string of invasions, and the Norman
> > Conquest was only the most recent.
> 
> The most recent invasion _into_ Great Britain perhaps, but surely not
> the most recent _invasion_ to have influenced the English language.  

Certainly English has had infusions of words since the Norman Conquest
from
Amerindian, Arabic, Chineese, French, German, Greek, Hebrew, Hindi,
Latin, 
Spanish, Yidish and a few others, but none have had the same influence.
With 
the universality of television and the coming universality of the
Internet, 
I expect to see a lot more loan words coming into English, along with
the 
continuing anglicization of other languages, e.g., "le drugstore" in
France, 
"lcampel (to compile) in Hebrew. But I don't expect to see anything
massive 
enough to call an invasion.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: maintenance of overriding subprograms

[Richard A. O'Keefe]

Richard A. O'Keefe wrote:
> This thread is based on initialise/initialize.
> I have real trouble with colour/color (I mean, English is French based,
> not Spanish based, right? (:-) (:-)).

Did no-one notice the smileys?
I am well aware of the history of English (including the substantial
influence of the native Celtic languages).
The point at issue here is the *writing* system, and it does actually
happen to be true that the English writing system is based on Norman
French scribal practices.  (The change from _written_ Anglo-Saxon to
_written_ Middle English is bigger than the change in the _spoken_
language.)

Concerning the OED and "ize/ise", I think it is worth pointing out
that the ize/ise variation extends into things the OED thinks it shouldn't.
In the last week, I have read two books where "surprise" was consistently
spelled "surprize".

Given the fact that there are two current writing systems for English,
not completely compatible, international standards would be well advised
to either _avoid_ words commonly spelled differently in these systems,
or to bless both versions.

For example, if plans to develop an international standard for Erlang
come to fruition, I will press for the existing
	-behaviour(Name).
declaration to be supplemented with a
	-behavior(Name).
declaration with identical meaning, despite the fact that the former is
my preferred spelling.

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: maintenance of overriding subprograms

[Robert Dewar]

<<When we compile, the compiler tells us that the package body of Root
does not have a corresponding body for Create. However, it does not tell
us that Derived.Create no longer overrides Root.Create; Derived.Create
silently changes from an overriding subprogram to a "normal" subprogram.
>>


Actually I think a warning would be in order if a primitive procedure
of a derived type matches the name (but not the signature) of a
procedure of its parent.

Re: maintenance of overriding subprograms

[Stephen Leake]

Robert Dewar wrote:
> 
> <<When we compile, the compiler tells us that the package body of Root
> does not have a corresponding body for Create. However, it does not tell
> us that Derived.Create no longer overrides Root.Create; Derived.Create
> silently changes from an overriding subprogram to a "normal" subprogram.
> >>
> 
> Actually I think a warning would be in order if a primitive procedure
> of a derived type matches the name (but not the signature) of a
> procedure of its parent.

That would solve the maintenance problem, while imposing the style
guideline that you should NOT give a subprogram the same name as a
parental procedure unless you are overriding it. This seems like a
reasonable guideline, and you could always disable the warning.

However, in addition to the maintenance problem (I had a hidden
requirement :), I would like the source to give more immediate
indication that we are intending the subprogram to override a parental 
one (and the others in the same spec do NOT). The presence/absence of
"new" or "pragma Confirm_Override" makes this clear. I think it makes
the source easier to read; one does not have to lookup all the primitive
parental procedures (a good tool would help, of course). This can be
done with comments, but those can get out of sync.
-- 
- Stephe

Re: maintenance of overriding subprograms

[Matthew Heaney]

In article <341065D7.4D41@gsfc.nasa.gov>, Stephen.Leake@gsfc.nasa.gov wrote:


>However, in addition to the maintenance problem (I had a hidden
>requirement :), I would like the source to give more immediate
>indication that we are intending the subprogram to override a parental 
>one (and the others in the same spec do NOT). The presence/absence of
>"new" or "pragma Confirm_Override" makes this clear. I think it makes
>the source easier to read; one does not have to lookup all the primitive
>parental procedures (a good tool would help, of course). This can be
>done with comments, but those can get out of sync.

Actually, this is one area where I thought the language designers were too
conservative.  I would have prefered that overriding subprograms be
explictly designated as such, using a keyword as "override", ie

type T is tagged private;

procedure Op (O : T);

type NT is new T with private;

override procedure Op (O : NT);

You should make the programmer assert his intent to override a primitive
operation, so he doesn't do it accidently.  This clearly documents which
primitive operations of a derived type override those of its parent.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: maintenance of overriding subprograms

[Robert A Duff]

In article <341065D7.4D41@gsfc.nasa.gov>,
Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:
>However, in addition to the maintenance problem (I had a hidden
>requirement :), I would like the source to give more immediate
>indication that we are intending the subprogram to override a parental 
>one (and the others in the same spec do NOT). ...

If I were designing a new language from scratch, I would probably do
this (that is, give some syntactic indication of the difference between
overriding vs. not overriding).  It doesn't seem easy to fit it into Ada
in a clean, simple way.  In particular, I don't like these suggestions:

>... The presence/absence of
>"new" or "pragma Confirm_Override" makes this clear. 

To me, "new" means "NOT overriding" -- that is, this subprogram
represents a *new* capability not available for the parent type, as
opposed to merely overriding an old capability.

I find the pragma idea to be in bad taste -- pragmas shouldn't have such
a strong effect on high-level semantics.

>...I think it makes
>the source easier to read; one does not have to lookup all the primitive
>parental procedures (a good tool would help, of course). This can be
>done with comments, but those can get out of sync.

Well, I suppose OOP-style programming is pretty hopeless without some
sort of tool that can show you the complete interface, with all the
inherited stuff included.

- Bob

Re: maintenance of overriding subprograms

[W. Wesley Groleau x4923]

> Well, I suppose OOP-style programming is pretty hopeless without some
> sort of tool that can show you the complete interface, with all the
> inherited stuff included.

If your names are well-chosen, and your hierarchy well-designed, 
wouldn't it be unnecessary (except for the occasional extreme case)
to hunt down a lot of other stuff to understand the item at hand?

Conversely, if one has to study all the ancestors in great detail
to do anything with a particular descendant, haven't we lost much of
the reduced work alleged to be acheived by inheritance?

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: maintenance of overriding subprograms

[Robert A Duff]

In article <34145A2F.3659@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
>If your names are well-chosen, and your hierarchy well-designed, 
>wouldn't it be unnecessary (except for the occasional extreme case)
>to hunt down a lot of other stuff to understand the item at hand?

I don't think so.  If I see:

    package P is
        type T is new Some_Parent with ...;
        procedure Foo(X: T);
    private
        ...
    end P;

How on Earth am I supposed to know about the 17 primitive operations of
type T?  If Some_Parent is heavily used, then maybe I've memorized them,
but otherwise, I can either go look them up, or use a tool that collects
them for me.  I prefer to have the latter, at least as an option.

>Conversely, if one has to study all the ancestors in great detail
>to do anything with a particular descendant, haven't we lost much of
>the reduced work alleged to be acheived by inheritance?

Well, not really.  For example, think of all those clients of the
*parent* type that happily use the derived type without even *knowing*
about it.

It depends who's doing the "alleging", I guess.  It ranges from "OOP is
a useful tool" to "OOP will cure all the world's ills".  ;-)

- Bob

Re: maintenance of overriding subprograms

[Jon S Anthony]

In article <EG8tAB.Et5@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <34145A2F.3659@pseserv3.fw.hac.com>,
> W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
> >If your names are well-chosen, and your hierarchy well-designed, 
> >wouldn't it be unnecessary (except for the occasional extreme case)
> >to hunt down a lot of other stuff to understand the item at hand?
> 
> I don't think so.  If I see:
> 
>     package P is
>         type T is new Some_Parent with ...;
>         procedure Foo(X: T);
>     private
>         ...
>     end P;
> 
> How on Earth am I supposed to know about the 17 primitive operations of
> type T?

Right.  You can't without looking them all up.  And it gets a _lot_
worse with MI.  This is just the old problem of OO (typically swept
under the rug by OO fanatics) that it can cause all sorts of
maintenance problems.

> >Conversely, if one has to study all the ancestors in great detail
> >to do anything with a particular descendant, haven't we lost much of
> >the reduced work alleged to be acheived by inheritance?

IMO, reducing work is not and never really has been a benefit of OO.
That's not what its good for.


> Well, not really.  For example, think of all those clients of the
> *parent* type that happily use the derived type without even *knowing*
> about it.

And possibly shooting themselves in the foot and generating all sorts
of maintenance nightmares to where the whole thing collapses under its
own bloated opaque weight.


> It depends who's doing the "alleging", I guess.  It ranges from "OOP
> is a useful tool" to "OOP will cure all the world's ills".  ;-)

To "OOP is outright dangerous" if not handled very carefully.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: maintenance of overriding subprograms

[Tom Moran]

>To me, "new" means "NOT overriding" -- that is, this subprogram
>represents a *new* capability not available for the parent type, as
>opposed to merely overriding an old capability.
Interesting.  I take 'new' to mean "new and improved version" rather
than "novel and unprecedented".

Re: maintenance of overriding subprograms

[Stephen Leake]

Tom Moran wrote:
> Bob Duff wrote:
> >To me, "new" means "NOT overriding" -- that is, this subprogram
> >represents a *new* capability not available for the parent type, as
> >opposed to merely overriding an old capability.
> Interesting.  I take 'new' to mean "new and improved version" rather
> than "novel and unprecedented".

I suggested "new" by analogy with dynamic allocation - "new" means
"here's another one". Also, I think it's the only current reserved word
that comes close to meaning what it needs to here.

I agree with Bob when he says a tool that shows the complete interface
is a requirement. Anyone working to make gnatf do this? Or do we need a
full ASIS to get there? I haven't been able to figure out how to get
Borland C++ to do this for C++ (I think it is supposed to), so I'm not
currently missing much. But it would be nice!

-- 
- Stephe

Re: maintenance of overriding subprograms

[Anonymous]

<341065D7.4D41@gsfc.nasa.gov> <EG54sG.D2F@world.std.com>
<34145A2F.3659@pseserv3.fw.hac.com>

On Tue, 9 Sep 1997 13:25:22 GMT, bobduff@world.std.com (Robert A Duff)
wrote:

> In article <34145A2F.3659@pseserv3.fw.hac.com>,
> W. Wesley Groleau x4923 <wwgrol@pseserv3.fw.hac.com> wrote:
> >If your names are well-chosen, and your hierarchy well-designed, 
> >wouldn't it be unnecessary (except for the occasional extreme case)
> >to hunt down a lot of other stuff to understand the item at hand?
> 
> I don't think so.  If I see:
> 
>     package P is
>         type T is new Some_Parent with ...;
>         procedure Foo(X: T);
>     private
>         ...
>     end P;
> 
> How on Earth am I supposed to know about the 17 primitive operations of
> type T?  If Some_Parent is heavily used, then maybe I've memorized them,
> but otherwise, I can either go look them up, or use a tool that collects
> them for me.  I prefer to have the latter, at least as an option.

How are you supposed to know about all the inherited operations of type
T? You aren't, and the tool you prefer will not be available when you
need it (I know this from experience). Note that this is true even if
Some_Parent is not tagged. Anyone who creates such code is not a
software engineer, since the result violates the principle of locality
and consists of highly coupled modules.

> 
> >Conversely, if one has to study all the ancestors in great detail
> >to do anything with a particular descendant, haven't we lost much of
> >the reduced work alleged to be acheived by inheritance?
> 
> Well, not really.  For example, think of all those clients of the
> *parent* type that happily use the derived type without even *knowing*
> about it.
> 
> It depends who's doing the "alleging", I guess.  It ranges from "OOP is
> a useful tool" to "OOP will cure all the world's ills".  ;-)

We've known for 30 years that high coupling among modules is bad. We've
also known for long enough that inheritance creates highly coupled
modules. Therefore, [conclusion left to the reader as an exercise].

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Go and boil your bottom."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: maintenance of overriding subprograms

[Marc Wachowitz]

jsa@alexandria.organon.com (Jon S Anthony) wrote:
> > How on Earth am I supposed to know about the 17 primitive operations of
> > type T?
> 
> Right.  You can't without looking them all up.  And it gets a _lot_
> worse with MI.  This is just the old problem of OO (typically swept
> under the rug by OO fanatics) that it can cause all sorts of
> maintenance problems.

This particular problem could be solved by following a well-established
design principle of Ada (which was, IMO unfortunately, not done in this
case), namely to favour ease of reading and clarity over ease of writing:
Simply have each subtype define _all_ its methods explicitly, making any
calls of supertype-methods explicit (something similar could be done for
instance variables of the parent, too). Along with this, clearly separate
subtyping (type compatibility) and inheritance (implementation), where
the latter may only be used to adapt existing implementations as fields
(subobjects) for new types, which results in a programming style more like
delegation, though still allowing to redefine some (maybe a restricted subset)
methods of the adapted type. Generally there would be no relation between
the types of the new type and whichever types it may adapt for implementation,
though where appropriate, both may of course be declared to support the same
interfaces. This results both in more explicit (and thus hopefully clear)
relations between various types/implementations, and in better decoupling.
Single inheritance (i.e. adaption of subobjects) would be sufficient; however,
adaptions for various subobjects and methods for the resulting new type should
be able to freely call each other.

For some similar ideas, see Michael Franz' paper on the language Lagoona,
http://http://www.ics.uci.edu/~franz/PDF/Lagoona-ics-tr-96-40.pdf

> > Well, not really.  For example, think of all those clients of the
> > *parent* type that happily use the derived type without even *knowing*
> > about it.
> 
> And possibly shooting themselves in the foot and generating all sorts
> of maintenance nightmares to where the whole thing collapses under its
> own bloated opaque weight.

That's why subtyping should be constrained to be "safe for the innocent".
For an excellent (IMO) approach to this, see the paper of Barbara Liskov
and Jeannette M. Wing on "Family Values: A Behavioural Notion of Subtyping",
http://www.dstc.edu.au/AU/research_news/odp/typemgmt/related_work/
                                                       behav_subtype.html
(the last two lines are supposed to be one URL).

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

Re: maintenance of overriding subprograms

[Marin David Condic, 561.796.8997, M/S 731-96]

 "John G. Volan" <johnv@AC3I.DSEG.TI.COM> writes:
>America, English has gained Amerindian words such as "okay", "squash",
>
    I thought the statement that "okay" was an American Indian word
    seemed to be incorrect - memory had me placing it as a U.S. slang
    term.

    A quick look at the OED (The New Shorter...) refreshed my memory.
    It originated from O.K. - representing the initials of Old
    Kinderhook, a nickname for President Martin Van Buren - hence also
    the hand gesture forming an "O-K" with the fingers.

    Back to the subject of Ada, Buckwheat?
    Oh-Tay 'Panky!

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
"I saw a bank that said "24 Hour Banking", but I don't have that much time."
        --  Steven Wright
===============================================================================