Unit Namen: namespaces wie in Delphi

[jammernich]

Hallo,

Entschuldigung, ich konnte das kaum in deutsch übersetzen. Es geht um die Unit-Namen mit .Notation wie in Delphi.

Ich habe ein paar Fragen dazu:

1) Welche freepascal Version brauche ich?
2) Wie funktioniert das? Was ist zu beachten? Wann anwenden?
3) Gibt es unterschiede zu Delphi?
4) Nutzt ihr dieses feature?

hier hab ich was gefunden dazu:
https://wiki.freepascal.org/FPC_New_Fea ... aces_units

[jammernich]

hier wird das nochmal erklärt. Frage 1 ist damit geklärt.
https://wiki.freepascal.org/Namespaces

[Warf]

"Namespaces" so zu nennen ist schon sehr optimistisch. Namespaces bedeutet einfach nur das man Punkte in Unit Namen haben darf. Mehr ist es nicht und hat semantisch auch keine Bedeutung (im Gegensatz zu echten Namespaces in anderen Sprachen).

Also im Grunde sind sie wie man bisher Units als prefix_name schreiben konnte, bzw. Wie z.b. die Jedi WinApi es gemacht hat JWAXXX kann man jetzt prefix.name schreiben. That's it.

Wie man geprefixte units benutzt ist jedem selbst überlassen, ich persönlich mach es manchmal so das ich eine Export unit hab die die ganzen subunits included und dann die Typen und Funktionen aus diesen Units exportiert das der Nutzer nur die export unit einbinden muss und nicht jede einzelne subunit kennen muss

[theo]

Das sehe ich auch so wie Warf.
Es ist schon OK, dass der FPC das um der Delphi Kompatibilität willen kann, aber sonst gibt es mMn nicht viel dazu zu sagen.
Ich bleibe im Zweifel lieber abwärtskompatibel, wenn ich in einem neuen Feature keinen grossen Nutzen sehe.

[m.fuchs]

Ich glaube hier wird ein bisschen was durcheinander gebracht.

Namespaces gibt es in Pascal schon eine Weile - jede Unit hat nämlich ihren eigenen. Deswegen kann ich die Prozedur MyProcedure sowohl in UnitA als auch in UnitB definieren und kann trotzdem beide Units und auch beide Prozeduren gemeinsam verwenden. Indem ich sie über ihren Namespace anspreche: UnitA.MyProcedure & UnitB.MyProcedure.

Hinzugekommen ist die Möglichkeiten Punkte im Unitname zu verwenden. Und diese Punkte haben durchaus Auswirkungen im Workflow. So kann ich mich mit in Lazarus mit Strg+Leerzeichen durch die einzelnen Namespaces durchhangeln. Beispiel: ich habe die Units Movie2Script.Forms.MainForm, Movie2Script.Forms.AboutForm, Movie2Script.Core.Model und Movie2Script.Core.Service.

Wenn ich nun "Movie2Script." eintippe und Strg+Leerzeichen drücke, erscheinen in der Auswahl nur die die beiden darunterliegenden Namespaces.

Bildschirmfoto zu 2025-03-08 14-29-40.png (23.14 KiB) 4163 mal betrachtet

Je nachdem was ich auswähle, Forms

Bildschirmfoto zu 2025-03-08 14-28-00.png (27.21 KiB) 4163 mal betrachtet

oder Core

Bildschirmfoto zu 2025-03-08 14-23-17.png (22.15 KiB) 4163 mal betrachtet

erscheinen dann nur die jeweiligen Units des entsprechenden Namespaces.

Das ist bei größeren Projekten schon ein Vorteil bei der Arbeit. Ich würde auf das Feature Dotted-Unitnames sehr ungern verzichten.

Was es hingegen nicht gibt (aber in einigen anderen Sprachen) sind mehrere Namespaces innerhalb einer Unit.

[jammernich]

Hallo und danke für die Antworten,

Also es gibt da gar keine Konvention sondern das hängt sehr vom Geschmack des Programmierers ab. Die Kompatiblität mit alten Delphi Versionen finde ich vernachlässigbar.

[theo]

Also es gibt da gar keine Konvention sondern das hängt sehr vom Geschmack des Programmierers ab.

Kann man so sagen. Bei grösseren Projekten kann man darüber nachdenken, aber als Einsteiger/Anfänger würde ich mir darüber keine Gedanken machen.

[Warf]

Hinzugekommen ist die Möglichkeiten Punkte im Unitname zu verwenden. Und diese Punkte haben durchaus Auswirkungen im Workflow. So kann ich mich mit in Lazarus mit Strg+Leerzeichen durch die einzelnen Namespaces durchhangeln.

Geht mir prefixen genauso, wenn ich in uses JWA eintippen und hinter dem A Steg+leer drücke dann schlägt mir Lazarus auch alle Jedi WinApi Units vor, da die alle JWA als prefix haben.

Es ist ein ganz klein wenig strukturierter, da es dir mit dem Punkt keine anderen Namen Vorschlägt in denen jwa vorkommen könnte, aber im Endeffekt gibt sich da nicht viel.

Der große Unterschied ist das prefixe meist nur ein paar Buchstaben sind (für meine LazTextForms hatte ich TF), und damit wahrscheinlicher in anderen bezeichnern. Und ich glaube das Unit namespaces einen dazu verleiten bessere prefixe zu wählen.

Aber im Endeffekt kann's nix was es nicht vorher schon konnte, und nix hindert dich prefix1_prefix2_name zu schreiben und mit Steg+space vervollständigen zu können

[multiplatform-coder]

"Namespaces" so zu nennen ist schon sehr optimistisch. Namespaces bedeutet einfach nur das man Punkte in Unit Namen haben darf. Mehr ist es nicht und hat semantisch auch keine Bedeutung (im Gegensatz zu echten Namespaces in anderen Sprachen).

Also im Grunde sind sie wie man bisher Units als prefix_name schreiben konnte, bzw. Wie z.b. die Jedi WinApi es gemacht hat JWAXXX kann man jetzt prefix.name schreiben. That's it.

Wie man geprefixte units benutzt ist jedem selbst überlassen, ich persönlich mach es manchmal so das ich eine Export unit hab die die ganzen subunits included und dann die Typen und Funktionen aus diesen Units exportiert das der Nutzer nur die export unit einbinden muss und nicht jede einzelne subunit kennen muss

Ich kriege aktuell bei Punkt im Unitnamen diese Compilerfehler:

constructors, destructors and class operators must be methods

und ";" expected aber "." gefunden. Muss ich, um Punkt im Unitnamen verwenden zu können irgendwas vorher einstellen?

[m.fuchs]

Welche Versionen?

[multiplatform-coder]

Lazarus 2.2.2, FPC 3.2.2

[multiplatform-coder]

Da ich für dioesen Test keine Namespaces brauche, habe ich die Punkte in den Unitnamen entfernt, nun funkt es wieder.

TUI steht nicht für (T)ext(U)ser(I)nterace, sondern für (T)est (U)nit (I)ncremental. Will mal was mit Unittests machen und da passt diese Unit hier, erster Test schon beim Compilieren fehl geschlagen.

[thosch]

Ups, da funktionieren Namespaces also auch mit Lazarus! Wieder was gelernt.

[af0815]

Lazarus 2.2.2, FPC 3.2.2

Naja, so taufrisch ist der Lazarus aber nicht.

3.8 ist da der aktuelle stable und du bist noch bei 2.x. Zumindest aktuell solltest du sein, weil gerade in Lazarus wurde sehr viel verbessert.

Und der 4.0 steht auch schon in den Startlöchern und hat schon die ersten RCs draussen.

[multiplatform-coder]

Ok, da habe ich also gestern auf Lazarus 3.8 aktualisiert. Sollte gelegentlich vorgenommen werden, solche Aktualisierung. Obwohl ich kein Freund permsnenter Updates bin. "Never change a running system" Wenn aber Probleme auftreten.....