Delphi Namespaces

[Neutral General]

Hallo,

Kann es sein dass Delphi-Namespaces der letzte Dreck sind? Habe mal einen Beispiel-Quelltext der einfach nur lächerlich ist.

Erstmal ein Zitat aus dem Emba-Wiki:

Zitat:

// in file 'unit1.pas'
unit MyCompany.ProjectX.ProgramY.Unit1

// in file 'unit2.pas'
unit MyCompany.ProjectX.ProgramY.Unit2

In diesem Beispiel enthält der Namespace MyCompany.ProjectX.ProgramY alle interface-Symbole aus unit1.pas und unit2.pas.
Symbolnamen in einem Namespace müssen für alle Units in dem Namespace eindeutig sein. Im obigen Beispiel wäre es ein Fehler, wenn für Unit1 und Unit2 ein globales Interface-Symbol namens mySymbol definiert wäre.

Jetzt mein Beispiel:

Delphi-Quellcode:

unit MeinKram.ErsteKlasse;

interface

type
  TErsteKlasse = class
  private
    FObjekt: TZweiteKlasse;   // #1
  public

  end;

  // Wie vom Wiki gesagt: es gibt einen Fehler weil die Klasse nur 1x pro Namespace definiert sein darf
  TZweiteKlasse = class       // #2

  end;

implementation

end.

Delphi-Quellcode:

unit MeinKram.ZweiteKlasse;

interface

type
  // Wie vom Wiki gesagt: es gibt einen Fehler weil die Klasse nur 1x pro Namespace definiert sein darf
  TZweiteKlasse = class
  private
    FObjekt: TErsteKlasse;
  public

  end;

implementation

end.

Beim compilieren bekomme ich 2 Fehler:

#1: [dcc32 Fehler] MeinKram.ErsteKlasse.pas(8): E2003 Undeklarierter Bezeichner: 'TZweiteKlasse'
#2: [dcc32 Fehler] MeinKram.ErsteKlasse.pas(13): E2004 Bezeichner redefiniert: 'TZweiteKlasse'

Da oben ist TZweiteKlasse undeklariert und ein paar Zeilen drunter ist er redifiniert? Das ist doch ein Witz oder?
So undeklariert kann TZweiteKlasse Klasse ja nicht sein wenn Sie ne Typdefinition weiter drunter laut Compiler redifiniert wurde..

Kann Embarcadero vllt. mal an ordentlichen Namespaces arbeiten? Das Beispiel zeigt doch wohl recht deutlich dass die Implementierung nicht mehr als ein Witz sein kann.

Wenn Sie es wenigstens nur "Punkte im Dateinamen von Units" nennen würden wäre es wenigstens ehrlich...

[Der schöne Günther]

Zitat von Neutral General:

Kann es sein dass Delphi-Namespaces der letzte Dreck sind? [...]
Wenn Sie es wenigstens nur "Punkte im Dateinamen von Units" nennen würden wäre es wenigstens ehrlich...

Genau meine Worte.

Das ist übrigens (in Kombination mit einem Gegenstück zum Java Default bzw. C# internal -Sichtbarkeitsmodifikator) das Einzige wo mich die Delphi-Sprache wirklich enttäuscht.

Closures oder Generics zu implementieren war doch sicher 100 mal schwerer als so etwas. Verstehen tue ich das auch nicht.

[himitsu]

Was passiert denn, wenn du probehalber die Punkte, in den Unitnamen, durch Unterstriche ersetzt?


#1 stimmt doch, auch ohne Namespaces.
Wenn du da die Forwarddeklaration der Klasse vergisst, welche erst danach deklariert wurde.
Oder soll das erste TZweiteKlasse in Unit1 das TZweiteKlasse aus Unit2 sein? (mit den Uses-Deklarationen wäre es vielleich verständlicher, also was nun wo drin hängt)

Das #2 könnte vielleich ein Folgefehler sein.



Ja, es sind nur "Punkte", aber über die Standard-"Namespaces" kann man Teile davon Variant halten und projektbezogen umschalten.
siehe FMX.Forms und VCL.Forms, wo man im Code nur Forms verwendet und dann die jeweilige Unit oassend zum Projekt verwendet wird.

[Stevie]

Zitat von himitsu:

Das #2 könnte vielleich ein Folgefehler sein.

Genauso isses. Der Fehler hat rein gar nichts mit den "punktierten Unitnamen" zu tun.
Das passiert auch bei ner Unit1, in den du diesen Code schreibst.

Da mir das Zitat aus der Dokumentation sehr komisch vorkam, hab ich das mal ausprobiert.
Meine Vermutung: Doku Altlasten von Delphi.NET (da gibt es einige).

Da es keine Namespaces in Delphi gibt, kann es auch keinen Namespace geben,
in dem ein Symbol nur einmal vorkommen darf.
Das ist nach wie vor auf eine Unit beschränkt mehr nicht.

Wenn du also in Klasse1 die Klasse2 nutzen willst und umgekehrt, kommst du um eine gemeinsame Unit nicht drumherum.

Zitat von himitsu:

Ja, es sind nur "Punkte", aber über die Standard-"Namespaces" kann man Teile davon Variant halten und projektbezogen umschalten.
siehe FMX.Forms und VCL.Forms, wo man im Code nur Forms verwendet und dann die jeweilige Unit oassend zum Projekt verwendet wird.

Genau. Lustigerweise ist die Funktionsweise ja nichtmal wie bei Namespaces. In Delphi kannste den vorderen Teil des Unitnamens weglassen (das ist dann aber mehr son "der Compiler versucht alle möglichen Kombinationen von Unitnamen aus, bis er was findet"). Daher auch die Empfehlung die von Embarcadero verwendeten "Namespaces" nicht in eigenen Units zu benutzen. Da könnte es halt schnell mal nen Konflikt geben.
Bei Namespaces hat der Unitname ja erstmal auch nix mit dem Namespace zu tun. Kannste locker in ne foo.cs eine Klasse für den Namespace Himitsu.LibraryBar.Whatever hinzufügen. Interessanterweise brauchst ja nichma die namespaces ins using schreiben, das wird ja über das einbinden der benötigten assemblies erledigt. Musste den Krams halt nur voll qualifizieren. Daher kann dir nen VS ja auch den entsprechenden Namespace vorschlagen, wenn du einen Typen benutzt, dessen Namespace noch nicht im using steht.