Gleichnamige Helfer-Klassen: Interface-Abschnitt hat Vorrang?

[Der schöne Günther]

Gegeben sei:

Delphi-Quellcode:

unit Unit1;

interface
   uses System.SysUtils;                 // Enthält ebenfalls einen TGUIDHelper
   procedure someProc(); forward;

   var myGUID: TGUID;

implementation
   uses Spring.Helpers;

   procedure someProc();
   begin
      if myGUID.IsEmpty then;
   end;

end.

Der TGUIDHelper aus Spring.Helpers hat eine Property IsEmpty , der aus System.SysUtils nicht. Die Code-Vervollständigung schlägt die Benutzung von IsEmpty vor. Beim Kompilieren aber wird gesagt

Code:

[dcc32 Fehler] Unit1.pas(15): E2003 Undeklarierter Bezeichner: 'IsEmpty'
[dcc32 Fataler Fehler] Project1.dpr(9): F2063 Verwendete Unit 'Unit1.pas' kann nicht compiliert werden

Ich habe also zwei record helper for System.TGUID : Einmal den aus System.SysUtils und einmal aus, beispielhaft, Spring.Helpers . Ich hätte erwartet dass der aus Spring.Helpers genommen wird, da dieser im implementation -Abschnitt importiert wird. Anscheinend ist dem nicht so.

Ob das so gewollt ist?
Habe ich etwas an der Delphi-Philosophie falsch verstanden? Weil sonst haben doch eigentlich immer später importierte Units und immer "implementation nach Interface" Vorrang...

[DeddyH]

Und wenn Du die Variablen-Deklaration auch in den implementation-Abschnitt verschiebst? Ich bin nicht sonderlich bewandert in Helpern, könnte mir aber vorstellen, dass das so klappt.

[Der schöne Günther]

Tatsächlich, im Beispiel oben macht das einen Unterschied- Dann nimmt er den "richtigen" Helper.

Aber im echten Fall war es ein geschütztes Feld einer Klasse. Keine globale Variable. Die bekomme ich aus dem interface-Abschnitt ja nicht heraus

[himitsu]

Grundsätzlich würde ich eh immer empfehlen möglichst alle Uses ausschließlich im Interface zu deklarieren.
Da kommt es dann auch nur noch auf die Reihenfolge drauf an, was letzendlich verwendet wird.
Und vorallem ist ausschließlich dort die Initialisierungsreihenfolge der Units richtig gegeben.
In die Implementation kommen bei mir ausschließlich Units, welche aufgrund von Kreuzreferenzen dort hin müsssen.


Außerdem halte ich es immernoch für einen grauenhaften Bug, daß Helper-Klassen nicht überladen werden, also daß immer nur ein Helper gleichzeitig pro Klasse/Typ aktiv ist.

Und ja, es wäre toll, wenn Compiler, Code-Insight und Error-Insight gleich arbeiten würden.

[Stevie]

Zitat von Der schöne Günther:

Tatsächlich, im Beispiel oben macht das einen Unterschied- Dann nimmt er den "richtigen" Helper.

Aber im echten Fall war es ein geschütztes Feld einer Klasse. Keine globale Variable. Die bekomme ich aus dem interface-Abschnitt ja nicht heraus

In dem Fall solltest du die Spring.Helpers unit in das interface uses aber nach der SysUtils setzen.
Wusste ich aber auch noch nicht, dass es bei Helpers eine Rolle spielt ob die uses und das geholfene () Symbol im gleichen Bereich stehen

[Der schöne Günther]

Aber wir sind uns doch alle (drei Leute immerhin) einig, dass das so eigentlich nicht sein sollte, oder? Es sollte immer die Helferklasse der "letzten" Unit zum Einsatz kommen. Steckt im interface -Teil schon eine, überschreibt die im implementation -Teil diese aber nicht. Aber sie sollte es.

Ist bei anderen Typen ja auch so.

[Stevie]

Zitat von Der schöne Günther:

Aber wir sind uns doch alle (drei Leute immerhin) einig, dass das so eigentlich nicht sein sollte, oder? Es sollte immer die Helferklasse der "letzten" Unit zum Einsatz kommen. Steckt im interface -Teil schon eine, überschreibt die im implementation -Teil diese aber nicht. Aber sie sollte es.

Ist bei anderen Typen ja auch so.

Es wäre zumindest ein konsistentes Verhalten. Wobei ich es natürlich begrüßen würde, wenn Helper sich nicht gegenseitig verdecken würden (zumindest nicht, wenn deren Member nicht auch noch gleich heißen).

Aber mit der Verbesserung von Helpern geh ich Marco sowieso bei jeder sich bietenden Gelegenheit auf die Nerven