Hello!

What if the line "inherited;" is automatically included when using code completion (<Ctrl><Shift>C) for constructor, destructor, CreateForm, DestroyForm, etc.? Instead of

    begin
    end;

it may be

    begin
        inherited;
    end;

Carlos Eduardo S. Matuzaki

---
Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190112/bfa653b4/attachment.html>

PM Carlos Eduardo S. M. wrote

What if the line "inherited;" is automatically included when using code completion (<Ctrl><Shift>C) for constructor, destructor, CreateForm, DestroyForm, etc.? Instead of

It already does if the method is declared with override.

Bart

Just "inherited" for constructors is afaik/iirc a major danger.

IIRC It only calls the parent method, if the parent method has the exact same signature.

If the call is made from within an "override" method, that is fine, because the override will fail if the parent changes.

If your method was re-introduced (maybe without the keyword / effectively hiding the parent), and the parent method changes, the "inherited" compiles (no error, no warning) but it will generate no code. Same for constructors, if the parent constructor changes its argument list, it will no longer be called.

That is indented behaviour and apparently Delphi compatible.

So always use the fully qualified call "inherited create;" (or with args as needed)

Martin Frb wrote

Same for constructors, if the parent constructor changes its argument list, it will no longer be called.

It does generate code, but it calls *any* inherited constructor that matches the signature:

  type
    TA = class
      constructor Create(extra:Boolean);
    end;
    TB = class(TA)
      constructor Create;
    end;
  constructor TA.Create(extra: Boolean);
  begin
    inherited Create;
    WriteLn('TA.Create');
  end;
  constructor TB.Create;
  begin
    inherited;                       // calls TObject.Create!
    WriteLn('TB.Create');
  end;

That is indented behaviour and apparently Delphi compatible.

Delphi 2007 fails compilation with "Incompatible Types" when no compatible method of the same name exists, which makes sense.

because TObject has a matching constructor.

Imagine it was

constructor TB.Create(extra: integer);

but was changed it TA.

Martin Frb wrote

> inherited; // calls TObject.Create! because TObject has a matching constructor.

Indeed. But in Delphi, "inherited without function name" stops looking after one mismatched argument list (just like override would), so it never gets to TObject.

FPC keeps going up the ancestor chain.

IMHO, `inherited;` and `inherited Create;` should be the same behavior. I don't use just `inherited;` and it isn't an issue for me, but it looks like an inconsistency on the language.

Using the example, both constructors _must_ call TObject.Create because `TA` haven't used `reintroduce` for the constructor.

Marcos Douglas

Well, I was told it was the same
https://bugs.freepascal.org/view.php?id=33862

Martin Frb wrote

Well, I was told it was the same https://bugs.freepascal.org/view.php?id=33862

Depends on how one reads the Emba Developer's comment.

""" In such case, a call to an inherited method may occur if it exists or not if it doesn't. Such a reference is limited to methods with the same name and parameter list *in the parent class* """ (emph. mine)

I would read that so that it only looks in *the* parent class, not "any ancestor class". If it finds nothing, it indeed generates no code and no error.

As observed, if it finds a matching name with wrong parameter list, an error is raised.

Fun Fact: if a matching name and parameter list exists and is virtual abstract, no code will be generated either. This is probably to protect from calls to virtual methods?

This is probably to protect from calls to virtual methods?

Sorry, meant to say "protect from calls to abstract methods", specifically from autogenerated code.