Keine Compiler-Warnung bei Unterklassen, dafür doppelt bei Interfaces

[Der schöne Günther]

Sorry für den langen Beitrag, es liest sich schneller als es aussieht.

Man nehme folgende Definition:

Delphi-Quellcode:

type
   TMyObject = class
      public
         procedure a(); virtual;
         procedure b(); experimental;
   end;

   TMySubObject = class(TMyObject)
      public
         procedure a(); override; experimental;
   end;

Rufe ich

Delphi-Quellcode:

b()

auf, erhalte ich in dieser Zeile eine Warnung

Delphi-Quellcode:

W1003 SYMBOL_EXPERIMENTAL

. Tue ich es nicht, erhalte ich keine Warnung. Soweit, alles bestens :thumb:

Nun zu Methode a(): Sie ist virtuell und wird in der Unterklasse überschrieben. Die Implementation möchte ich als

Delphi-Quellcode:

experimental

kennzeichnen. Ich erhalte aber weder eine Warnung beim Instanziieren einer

Delphi-Quellcode:

TMySubObject

-Instanz, noch beim Aufrufen der Methode

Delphi-Quellcode:

TMyObject.a()

:

Delphi-Quellcode:

procedure p();
var
   myObject: TMyObject;
begin
   myObject := TMySubObject.Create();
   myObject.a(); // Keine einzige Warnung
end;

Das kann man wahrscheinlich sogar irgendwie begründen, aber ich sehe spontan nur dass es beispielsweise völlig inkonsistent ist wenn ich die Klasse nun ein Interface implementieren lasse:

Delphi-Quellcode:

type
   IMyInterface = interface
      procedure a();
      procedure b();
   end;

   TMyObject = class(TInterfacedObject, IMyInterface) // << W1003
      public
         procedure a(); experimental;
         procedure b();
   end; // << W1003

Hier wirft die Deklaration von

Delphi-Quellcode:

TMyObject

gleich zwei mal die selbe Warnung, selbst wenn die Klasse

Delphi-Quellcode:

TMyObject

nirgendwo im Code verwendet und vom Linker wieder entfernt wird.

Spätestens jetzt komme ich überhaupt nicht mehr hinterher. Macht das alles noch irgendwie Sinn und ich sehe den nur nicht?

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1393830)

Delphi-Quellcode:

//Keine einzige Warnung

Das kann man wahrscheinlich sogar irgendwie begründen

Natürlich, denn in TMyObject ist es nunmal nicht experimental.
TMyObject kennt das TMySubObject garnicht und kann demnach auch nicht darauf reagieren, außerdem weiß der Compiler bei myObject nicht was zur Laufzeit für eine Instanz drin ist, somit kann er sich nur auf die Deklaration von TMyObject stüzen.


experimental ist halt ein experiemtelles Feature, was sonst niemand verwendert ... gut möglich, dass es bei den Interfaces ein paar unentdeckte Bugs gibt. :stupid:

[Uwe Raabe]

Eigentlich ist experimental nur für Units gedacht:

Zitat:

The Delphi compiler also recognizes the hinting directive experimental. You can use this directive to designate units that are in an unstable development state. The compiler will emit a warning when it builds an application that uses the unit.

Der Fehler besteht darin, daß der Compiler das überhaupt an dieser Stelle akzeptiert.

[Der schöne Günther]

Zitat:

Zitat von himitsu (Beitrag 1393834)

Natürlich, denn in TMyObject ist es nunmal nicht experimental.
TMyObject kennt das TMySubObject garnicht und kann demnach auch nicht darauf reagieren

Das macht Sinn, aber diese Begründung passt doch ebenso auf den Fall mit dem Interface. Und da ist es dann plötzlich genau anders herum.

Zitat:

Zitat von Uwe Raabe (Beitrag 1393837)

Eigentlich ist experimental nur für Units gedacht

Vorsicht, es gibt die Warnungen W1003 SYMBOL_EXPERIMENTAL sowie W1007 UNIT_EXPERIMENTAL (Quelle)

Ich kann auch einer ganzen Unit ein experimental verpassen, aber sehr wohl auch einzelnen Methoden oder ganzen Klassen. Der eingangs geschilderte Fall mit der Methode

Delphi-Quellcode:

b()

ist ja auch ein absolutes Positivbeispiel, so sollte es sein.