[fpc-pascal] Inherited and not virtual/overridden procedures

[Max Vlasov]

On Wed, Jun 12, 2013 at 2:12 AM, Bart <bartjunk64 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130612/d0a3b5a4/attachment.html>