wann gibt es in Delphi einen NAMESPACE wie in c#

[Neutral General]

Zitat:

Zitat von Uwe Raabe (Beitrag 1340937)

Wenn Namespaces also sonst nichts zu bieten haben...

Namespaces lösen quasi das Problem von zirkulären Referenzen. Eine der Sachen die mich in Delphi wirklich stören.
Und von Dependency Injection kann man auch nicht sprechen. Es werden beim benutzen eines Namespaces ja nur der Code eingebunden der im Projekt bzw. der Projektgruppe enthalten ist und der Code (in Form einer DLL) den man explizit zur Designzeit als Referenz dem Projekt hinzugefügt hat. Es kann also niemand irgendwo einfach eine Quelltextdatei mit einem Namespace ablegen der dann plötzlich in meinen Code einkompiliert wird. Sowas wie Suchpfade/Bibliothekspfade gibt es in C# nicht.

Ich würde dir aber empfehlen mal ein bisschen mit C# zu arbeiten. Du wirst dann die Vorteile von Namespaces schnell erkennen.
Namespaces sind jetzt nichts was die Welt verändert, aber sie haben soweit ich das abschätze keine Nachteile und sind definitiv besser und praktischer als "Unitnamen mit Punkten".

[Sir Rufo]

Die Namespaces lösen dieses Problem nicht, sondern der generelle Aufbau des Compilers.

Bei C# kann quasi jeder kleine Fitzelkram in einer eigenen Datei stehen. Selbst Klassen kann ich über mehrere Dateien verteilen (partial class).

Das führt aber zum nächsten Problem, wie wo was gehört denn nun zusammen. Dafür sind diese Namespaces, denn damit bekommt man eine Struktur.

[mjustin]

Zitat:

Zitat von Uwe Raabe (Beitrag 1340937)

Da muss ich mich dann aber wirklich fragen, ob ich das überhaupt will, daß plötzlich eine neu auftauchende Unit irgendwo im Suchpfad, die mit einem "VCL." beginnt, meinen Scope infiltriert, den ich durch eine

Delphi-Quellcode:

using VCL

gesetzt habe. Das wäre dann ja echt Dependency Injection :twisted:

Ich bin zwar kein .NET namespace Experte, aber in der Java Welt ist es völlig normal, genau diesen Effekt zu nutzen, um in einem bestimmten Kontext nicht funktionierende Klassen durch andere Implementierungen zu überschreiben. Die neue Klasse muss dazu nur weiter vorher im classpath erscheinen. Allerdings ist der classpath in Java auch besser kontrollierbar als der Suchpfad in Delphi. Klassen müssen ausserdem in einem Verzeichnis liegen, das mit dem package (das Pendant zum namespace) übereinstimmt, andernfalls wird der Compiler abbrechen (im Gegensatz zur.NET Welt, wo namespaces und Verzeichnisstrukturen nach Lust und Laune divergieren dürfen).

Gänzlich aus dem Nichts auftauchende Dateien würden mich allerdings programmiersprachenunabhängig etwas irritieren - höchste Zeit meine Anmeldepasswörter zu ändern :)

[Uwe Raabe]

Zitat:

Zitat von mjustin (Beitrag 1340940)

Gänzlich aus dem Nichts auftauchende Dateien würden mich allerdings programmiersprachenunabhängig etwas irritieren - höchste Zeit meine Anmeldepasswörter zu ändern :)

Nicht unbedingt. Das kann auch einfach durch eine neuere Version einer Bibliothek geschehen oder durch einen Kollegen, der mal eben eine neue Unit mit RTL oder VCL prefixt oder sowas.

Ich verstehe, daß die tatsächlich eingebundenen Units bei C# durch einen anderen Mechanismus bestimmt werden, aber bei Delphi sind das nun mal die Uses-Anweisungen und die Suchpfade. Solange das so bleibt und keine andere Möglichkeit besteht, die tatsächlich eingebundenen Units (wir reden hier ja nicht von Assemblies oder Packages) zu beschränken, sehe ich hier eher Probleme mit Namespaces in Delphi.

Aber ich bin ja lernwillig und würde gerne über konkrete Fälle erfahren, in denen Namespaces signifikante Vorteile bringen würden. Ob die Vorteile oder die Nachteile (die dann ja auch von der tatsächlichen Implementation abhängen) überwiegen, kann dann ja jeder für sich entscheiden.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1340937)

das Einfügen einer ganzen Gruppe von Units eines Namespaces (oder auch nicht Namespaces) bekomme über den ModelMaker Code Explorer auch mit wenigen Tastendrücken hin (z.B. VCL.Bind: <CTRL>-U, "vcl.bind", <Tab>, <PgDn>, <Alt>-S).

#IDEVomit

Zitat:

Zitat von Uwe Raabe (Beitrag 1340942)

Das kann auch einfach durch eine neuere Version einer Bibliothek geschehen oder durch einen Kollegen, der mal eben eine neue Unit mit RTL oder VCL prefixt oder sowas.

Deshalb ist ja auch bei richtiger Namespace Implementierung der Unitname wurscht. Ausschlaggebend ist, in welche Namespace ich den Krams packe, der in der neuen Unit steht. Und wenn ich nunmal uses VCL schreibe, dann muss ich mir im Klaren sein, dass ich mir alles reinziehe.

[Memnarch]

Zitat:

Zitat von luisk (Beitrag 1340926)

[...]
Was soll eigentlich noch dieses Compiler-Gedöns ?
PHP läuft doch als Interpreter auch extrm schnell.
Es sollte doch kein Problem sein, dieses Konzept auf Applikationen anzuwenden.

Auch eine Scriptsprache nutzt einen Compiler ;). Beschäftige dich bitte mit dem Topic "Was ist ein Compiler".

[himitsu]

Also wenn man es so sieht, dann gibt es doch NameSpaces?

Wie schon erwähnt sind nicht die Punkte in Unitnamen, auch wenn man die Entfernt mit dazu zählen kann.


Namespace anlegen, also

Delphi-Quellcode:

type MeinNamespace = record {oder class} .... end;

drumrum, um die Definition,
und im Code dann mit dem coolen WITH-DO arbeiten. :stupid:

Zitat:

Zitat von Sir Rufo (Beitrag 1340939)

Bei C# kann quasi jeder kleine Fitzelkram in einer eigenen Datei stehen. Selbst Klassen kann ich über mehrere Dateien verteilen (partial class).

Mit Include-Dateien kann man das (bedingt) auch im Pascal, aber ich würde das nicht wirklich in großem Maßstab einsetzen wollen.

[Neutral General]

Zitat:

Zitat von Memnarch (Beitrag 1340971)

Auch eine Scriptsprache nutzt einen Compiler ;). Beschäftige dich bitte mit dem Topic "Was ist ein Compiler".

Nicht zwangsweise. Auch wenn das heutzutage größtenteils der Fall ist gibt es auch Skriptsprachen in denen der uncompilierte Quelltext direkt interpretiert wird.

[luisk]

Zitat:

Zitat von Bambini (Beitrag 1340934)

Zitat:

Zitat von luisk (Beitrag 1340926)

Zitat:

Zitat von Bambini (Beitrag 1340853)

"nightly builds" :-D

Was soll eigentlich noch dieses Compiler-Gedöns ?
PHP läuft doch als Interpreter auch extrm schnell.
Es sollte doch kein Problem sein, dieses Konzept auf Applikationen anzuwenden.

Für ein "paar" Strings zu lesen und schreiben mag es schnell genug sein. Aber auch die Runtime von PHP ist compiliert;-)
Komplexe Anwendungen mit eigener UI's zu bauen erfordern schnellen Code. Warum sollte man diesen nicht schon bei der Erstellung erzeugen?

PHP ist bei Netzwerkzugriffen und Datenbankzugriffen so schnell wie Delphi
und ein Webbrowser ist seltsamerweise mit HTML und Javascript schneller als Delphi.
Delphi-FMX ist nun zwar schneller als unter VCL, aber für den Stand der Technik zu langsam.
Die scrollbaren Layout-Controls kommen bei größeren Objektmengen schnell an ihre Grenzen.
- Da muss man dann halt immer noch selber was zusammenbauen.

Was mit PHP, HTML und Javascript funktioniert sollte doch auch mit einer sauberen objektorientierten Programmiersprache funktionieren. Autos und Industrie 4.0 Objekte sollen sich demnächst in Echtzeit unterhalten
und die Programmiersysteme sind inzwischen schon mehr als grenzdebil.

Wollte gestern man Xamarin Visual Studio installieren. Als ich die angedeutete Installationszeit sah hab ich wieder abgebrochen.


Tja, hätte mich vor 20 Jahren einer gefragt, wo die Programmiersprachen 2016 stehen,
dann hätte ich mit nicht so ein Gebastel vorstellen können - aber was soll´s, wir werden ja auch älter und gebrechlicher.
Das einzige, was sich kontinuierlich weiterentwickelt ist die Zeit an sich.
(Einstein hat da ja was anderes herausgefunden :wink:)

[luisk]

zum Thema Namespace:
Delphi arbeitet da ja im Prinzip mit überflüssigen und redundanten Informationen.
Man muss die Units ja eh zum Projekt hinzufügen un dann noch mal in jeder Unit die anderen bekanntgeben.
Wenn ich ein Formular in einem weiteren anspreche fragt mich der Editor doch ob er diese Unit
mit dem Formular zu den uses hinzufügen soll. Also kennt das System doch die erforderlichen Zusammenhänge.