On Wed, Jun 12, 2013 at 2:12 AM, Bart <bartjun...@gmail.com> wrote: > > I thought that if I had a subclass that inherited form a parentclass, > and both have a method with the same name (Bar), then the method of > the subclass hid the method of the parentclass, and you could not call > inherited Bar in the subclass. > > I see your point, but this question is more to the original designers of Delphi. I tried to look at real life examples from VCL (to find the roots of the "devil" :)) and there are cases when it's unavoidable
- Constructors call inherited no matter whether they're virtual or not. It just feels right to allow this. - Message handlers call inherited. Technically they're similar to virtual methods so this is something that should have work even if calling inherited from non-virtual methods is prohibited. - Any method of ClassA(ClassB) can call inherited ClassB.SomeMethod if it's accidentally has the same name as SomeMethod of ClassA. - Most of the cases in the VCL is a kind of "type override: when one inherits from TCollection and want to add own Add with the new type of the item (to be sure no other types will be accepted). So in the body it's basically calling inherited Add with a typecast. - An interesting case: TRegIniFile = class(TRegistry). There are many methods having the same name, but different parameters list. So, it's more semantic inheritance so if you replace the existing code working with registry, you just have to slightly change actual parameters of the methods called. Overall looking at all cases I think this keyword can be considered as a good universal prefix excluding the context of the existing class working with methods and properties. Even looking at the name it has more to do with INHERITance than polymorphism Max
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
