![]() |
wann gibt es in Delphi einen NAMESPACE wie in c#
wann gibt es in Delphi einen NAMESPACE wie in c# :idea:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Nächsten Dienstag.
Nein ehrlich, das (inkl. einem Sichtbarkeitsmodifikator analog zu "package" (Java) / "internal" (C#) ist auch mein #1-Feature das ich mir für die Sprache Delphi wünschen würde. Aber insgesamt habe ich da eher wenig Hoffnung. Solche Basics stecken wahrscheinlich ganz tief im Compiler-Teil der seit 20 Jahren nicht mehr angefasst wurde :-D |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Win32, Win64, MacOS und auch für den iOS Simulator, sind das die "alten" Compiler. die NexGen Compiler kann man sehr gut an der Compiler-Geschwindigkeit erkennen. Sollte das in die Win32/64 Einzug halten, könnte beim Drücken der F9 Taste, bei großen Projektten, Stunden vergehen. Dann gibt es bei Delphi endlich auch "nightly builds" :-D |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Das würde eher bedeutet... Vergiss Delphi... |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Schaut man sich den C++-Builder an, kann man hier seit 10.1 Berlin frei wählen ob man den "alten" oder den neuen LLVM-Compiler für Win32 haben möchte und frei hin- und her wechseln. Nur als Hinweis am Rande :-)
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
NAMESPACES wie in c# gibt es nicht.
Es gibt aber die möglichkeit "Namespaceartik" seine Dateien zu benennen so das die Probleme wie früher "Bibliothek x hat eine unit abc.pas, Bibliothek y hat eine Unit mit gleichen Namen und unterschiedlichen inhalt" keine Problem mehr versacht, da die eine Unit als "BibliothekX.abc.pas" und die andere als "BibliothekY.abc.pas" im Dateisystem vorliegt und mit "BibliothekX.abc" ansprachbar ist. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Delphi-Quellcode:
schreiben und hab alles drin, was im Namespace ist und muss nicht öffzig BibliothekX.... units einbinden.
uses BibliothekX
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
*Weg renn* Sherlock |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
"Unit" ist ja kurioserweise das, was in Pascal einem Namensraum noch am nächsten kommt (siehe [strict] private/protected). Spaß macht das aber keinen mehr.
Ich hatte mir mal überlegt ob man nicht tatsächlich so eine einzelne Unit "MyNamespace.pas" machen könnte die nur aus "{$Include MyNamespace.Class1.pas}" bis "Class99" besteht. Das habe ich aber noch nirgendwo gesehen, deshalb ist es wohl eine Schnapsidee. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Aber schön ist was anderes. Genauso wie Namespaces in Delphi - sage wir mal so - "Optimierungsmöglichkeiten" besitzt. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
PHP läuft doch als Interpreter auch extrm schnell. Es sollte doch kein Problem sein, dieses Konzept auf Applikationen anzuwenden. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Komplexe Anwendungen mit eigener UI's zu bauen erfordern schnellen Code. Warum sollte man diesen nicht schon bei der Erstellung erzeugen? |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
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:
gesetzt habe. Das wäre dann ja echt Dependency Injection :twisted:
using VCL
Ach ja: 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). Wenn Namespaces also sonst nichts zu bieten haben... |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
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". |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
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. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Gänzlich aus dem Nichts auftauchende Dateien würden mich allerdings programmiersprachenunabhängig etwas irritieren - höchste Zeit meine Anmeldepasswörter zu ändern :) |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
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. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
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:
drumrum, um die Definition,
type MeinNamespace = record {oder class} .... end;
und im Code dann mit dem coolen WITH-DO arbeiten. :stupid: Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
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:) |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
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. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
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. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
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. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
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). |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
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. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Nimm eine Tabelle mit 3000 Datensätzen. Pro Datensatz nimmst Du ein Layout, in dem du die weiteren Attribute visualisierst. Und das alles legst Du in eine Scrollbox. Das Ding bricht Dir zusammen. Ich behelfe mir Folgendermaßen: Ich nehm ein einfaches Layout und einen separaten Scrollbar. Im Layout habe ich dann nur so viele Satzlayouts, wie sichtbar sind. Das Scrollen mach ich dann selber. Läuft dann butterweich und schnell. Das ganze mit PHP/HTML und CSS - kein Problem. Weiter: die Stringrids in Delphi in kommen nie und nimmer an die Performance von Tabellen in HTML ran. Ich würde Embarcadero meine Unterstützung anbieten :wink: die preifen aber drauf :P |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Damit ergeben sich sehr viele Pfade, also gibt es nicht nur einen Suchpfad. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Welche weiteren Attribute? Attribute von was? Zitat:
Ich hab das Gefühl dass sie auf deine Unterstützung aus gutem Grund pfeifen :roll: |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
Zitat:
|
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
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. |
AW: wann gibt es in Delphi einen NAMESPACE wie in c#
Zitat:
In Delphi ein Tabelle ebenfalls mit 3000 Datensätzen und Visualisierungen von Feldern In Delphi ist die Tabelle "in 0,Nix" aufgebaut. Im Browser kämpft sich ein IE durch und braucht merklich länger als die Delphi-Lösung und genehmigt sich auch viel mehr speicher. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:48 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 by Thomas Breitkreuz