wann gibt es in Delphi einen NAMESPACE wie in c#

[Bambini]

Zitat von luisk:

Zitat von Bambini:

"nightly builds"

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?

[luisk]

Zitat von Bambini:

Zitat von luisk:

Zitat von Bambini:

"nightly builds"

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 )

[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.

[Uwe Raabe]

Zitat von luisk:

z
Man muss die Units ja eh zum Projekt hinzufügen un dann noch mal in jeder Unit die anderen bekanntgeben.

Muss man nicht. Es genügt, wenn die Unit im Suchpfad liegt.

Etwas anderes ist es mit dem Formular-Editor. Der muss die Instanzen der Formulare und Datenmodule kennen, damit er die untereinander verlinken und eine eventuelle Vererbung regeln kann. Deswegen steht in der Uses-Anweisung der DPR bei Forms, Frames und Datamodules auch noch etwas mehr. Ein völlig unabhängiges Form oder Datenmodul, daß dynamisch erzeugt wird, muss nicht zum Projekt hinzugefügt werden.

[luisk]

Zitat von Uwe Raabe:

Muss man nicht. Es genügt, wenn die Unit im Suchpfad liegt.

Um den Überblick zu behalten strukturiere ich meine Projekt über die Baumstruktur der Projektverwaltung.
Damit ergeben sich sehr viele Pfade, also gibt es nicht nur einen Suchpfad.

[Uwe Raabe]

Zitat von luisk:

Zitat von Uwe Raabe:

Muss man nicht. Es genügt, wenn die Unit im Suchpfad liegt.

Um den Überblick zu behalten strukturiere ich meine Projekt über die Baumstruktur der Projektverwaltung.
Damit ergeben sich sehr viele Pfade, also gibt es nicht nur einen Suchpfad.

Mache ich auch. Mit Suchpfad meinte ich auch nicht nur einen Pfad im Dateisystem. Bei einigen Projekten kommt da schon eine stattliche Liste zusammen.

Andererseits, wenn man eine Unit direkt in das Projekt aufnimmt, braucht man dafür aber den Pfad in der Regel nicht mit in die Suchpfade aufnehmen. Die sind nur für die Dateien notwendig, die nicht explizit im Projekt hinterlegt sind.

[Rollo62]

@Luisk

Was du schreibst mag ja sein, hat aber mit Namespaces sehr wenig zu tun.
Es gibt auch immer zig Wege etwas umzusetzen.
Das JavaScript und Konsorten schlanker sind und sich als "Assembler" des Webs durchsetzt
ist ja möglich, aber die Tools dafür sind ziemlich Kommandozeile und Stückwerk.
Genau deswegen bin ich ja bei Delphi.

Mit den Suchpfaden hast du Recht, ich würde mir auch wünschen ich könnte relative
Pfade mit den Units angeben, das geht so zumindest im DPR, also unmöglich ist es nicht.

Rollo

[Neutral General]

Zitat von luisk:

ein Webbrowser ist seltsamerweise mit HTML und Javascript schneller als Delphi.

Was? Da hätte ich aber gerne ein Beispiel/Beweis wenn du sowas in den Raum wirfst.
Und das FMX schneller als die VCL ist kann ich mir auch nicht vorstellen, aber da will ich mich jetzt nicht zu sehr aus dem Fenster lehnen.

[Bernhard Geyer]

Zitat von Neutral General:

Zitat von luisk:

ein Webbrowser ist seltsamerweise mit HTML und Javascript schneller als Delphi.

Was? Da hätte ich aber gerne ein Beispiel/Beweis wenn du sowas in den Raum wirfst.
Und das FMX schneller als die VCL ist kann ich mir auch nicht vorstellen, aber da will ich mich jetzt nicht zu sehr aus dem Fenster lehnen.

Das wir vermutlich nur in einzelfällen der Fall sein. Genau die Einzelfälle in dem ein schlecht entwickeltes Assembler-Programm langsamer ist als ein optimiertes VB-Programm.
I.d.R. wird ein VCL-Programm (wenn man nichts falsch macht) schneller sein als die entsprechende Browser-Lösung.
Ich schaffe es aber auch das mein VCL-Programm um welten langsamer ist als eine Browser-Lösung (gilt aber auch umgekehrt).

[Neutral General]

Ja gut ich gehe davon aus dass man nicht Äpfel mit Birnen vergleicht.
Aber ich bezweifle dass ein Algorithmus bei gleicher/äquivalenter Implementierung im Webbrowser schneller ist als bei einem mit Delphi geschriebenen Programm.