Ähm... Wer sagt denn dass ein Constructor unbedingt "Create" heißen muss? Nenn den in der Kindklasse eben "CreateNew", was ja nicht unüblich ist.
Technisch gesehen hast du Recht. In der Praxis wird mir schlecht wenn ich Konstruktoren sehe, die nicht "Create" heißen.
Oder alternativ, den Konstruktor der Basisklasse einfach gar nicht erst virtual deklarieren. Die besagte Compilerwarnung hat schon ihre Berechtigung. Denn es hindert dich ja nichts daran, in der Kindklasse einen Konstruktor mit identischer Parameterliste wie in der Elternklasse zu deklarieren. Spätestens dann hättest du ein Scope-Problem.
Das hier ist nur ein Beispiel. Im Original ist TBasis eine Ableitung von TComponent, bei der der constructor Create(AOwner: TComponent) nunmal virtuell ist.
Die Compilerwarnung hat NUR DANN eine Berechtigung wenn ich in der Ableitung tatsächlich einen Konstruktor definiere mit den gleichen Parametern wie er schon in der/einer Elternklasse existiert.
Das ist aber hier nicht der Fall, daher kein Scope Problem und keinen Grund für die Warnung.
Der scheinbar vererbte Konstruktor wird dir auch nur in der selben
Unit in beiden Varianten in der Codevervollständigung angezeigt. In einer anderen
Unit erscheint nur der Konstruktor der Kindklasse. Ist wohl die selbe "Baustelle" wie die Tatsache, dass man in der selben
Unit auch in Kindklassen auf private-Variablen der Elternklasse zugreifen kann.
Das ist schlichtweg falsch:
Formular:
Unit4:
Besser man gewöhnt sich so einen Schluderladen aus überladenen virtuellen Konstruktoren gar nicht erst an. Denn in der Praxis kann man meistens nur einen davon gebrauchen weil der andere die Kindklasse gar nicht richtig initialisiert.
Das kann man so auch nicht verallgemeinern.
In den meisten Fällen hast du Recht, aber es gibt eben auch Fälle wo der Konstruktor des Kinds nur ein "Bonus" ist und auch der Elternkonstruktor das Objekt ausreichend initialisiert.