From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,896d86ef3723978c X-Google-Attributes: gid103376,public From: Stephen Leake Subject: Re: maintenance of overriding subprograms Date: 1997/09/05 Message-ID: <341065D7.4D41@gsfc.nasa.gov>#1/1 X-Deja-AN: 270052623 References: <340C2EA5.B9F@gsfc.nasa.gov> Reply-To: Stephen.Leake@gsfc.nasa.gov Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Newsgroups: comp.lang.ada Date: 1997-09-05T00:00:00+00:00 List-Id: Robert Dewar wrote: > > < 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