![]() |
Delphi-Version: XE4
Delphi Namespaces
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:
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:
Beim compilieren bekomme ich 2 Fehler:
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. #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... :roll: |
AW: Delphi Namespaces
Zitat:
Das ist übrigens (in Kombination mit einem Gegenstück zum Java
Delphi-Quellcode:
bzw. C#
Default
Delphi-Quellcode:
-Sichtbarkeitsmodifikator) das Einzige wo mich die Delphi-Sprache wirklich enttäuscht.
internal
Closures oder Generics zu implementieren war doch sicher 100 mal schwerer als so etwas. Verstehen tue ich das auch nicht. |
AW: Delphi Namespaces
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. |
AW: Delphi Namespaces
Zitat:
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:
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz