At 09:22 PM 10/14/98 GMT, Matthew Heaney wrote: >Although I'm generally happy with Ada95, I feel that not requiring >programmers to explicitly state that an operation overrides that of its >parent, is a language flaw. Personally I don't think it is. But the easiest solution to this problem is in the hands of the compiler vendors. It is not unusual for a (non-overriding) operation to have a different parameter and result profile: function Create return Foo; ... type Foobar is new Foo with Bar; function Create(B: in Bar) return Foobar; It is not unusual for a non-overriding operation to be declared where it won't be inherited, although you often want to use 'Class in such cases. with Lists; ... procudure Foob(A: Anything; L: in Lists.List...); But it is unusual for a non-overriding inheritable operation to be declared with the same parameter and result profile as an inherited operation that is not overrriden, especially if the two have similar names. So in such cases, a compiler can print a warning. A warning which did no comparisions on names would probably be a bit much, but one that just checked for the same initial letter would be right more often than wrong, and I'm sure that compiler writers can come up with better criteria. In fact, there is another closely related anomaly that existed in Ada 83 that I think compilers should warn about, since is much more likely in Ada 95: type Foo is ...; function Get return Foo; type Bar is new Foo; function Get(From: Ada.Text_IO.File_Type := Ada.Text_IO.Current_Input) return Bar; B: Bar := Get; -- ambiguous C: Bar := Bar'(Get); -- still ambiguous! The derived Get can't be called, but it prevents the new Get from being called using the defaults. Take out the default, or better: type Bar is new Foo; function Get return Bar; function Get(From: Ada.Text_IO.File_Type) return Bar; ... function Get return Bar is begin return Get(Ada.Text_IO.Current_Input); end; Gives the originally intended effect. Again, an intelligible warning will allow the progammer to fix the problem and proceed onward. Waiting until the point of call doesn't help. This is a mistake on the part of the person writing the package, not the caller of the package. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...