Delphi für .NET <> Delphi Win32

[Bernhard Geyer]

Zitat:

Ich meine das Net sich zwischenzeitlich bei MFC und VB Entwicklern durchgesetzt hat.
Spätestens mit der nächsten Windowsversion, wenn Net Bestandteil des Betriebssystems ist

Wollt M$ das nicht schon mit W2003 machen?

Zitat:

Teile der Funktionalität nur noch in Net und nicht mehr in einer W32 API zur Verfügung stehen
wird MS sein Ziel erreicht haben.

Ist doch heute schon so. Aber mit Managed VCL kommt man auch ohne COM-Wrapping darauf hin.

Zitat:

Das IX Sonderheft zu Net gibt im angelsächsischen Sprachraum eine Verbreitung von 50% der
Entwickler an. Für Deutschland etwa 40 %.
Schaut man auf Gulp in die Projektstatistik, dann hat Net Java deutlich überholt.
Delphi hat auf Gulp noch nie eine große Rolle gespielt und dümpelt unter 1%.

Wie war das noch mit der Aussagekraft von Statistiken. Es gibt (bezüglich Java <-> .NET) genügend Statistiken die Java noch im Vorteil sehen...

Zitat:

Ich selbst entwickle kommerziell noch mit Delphi 32, sehe aber bei einer Reihe Firmen eine Absetzbewegung
in Richtung Net.

Stimmt. .NET holt auf. Aber wenn Du nur eine Exe verkaufst so sieht der Normale Anwender ihr nicht an ob sie .NET oder Win32 ist. Ich denke mit Avalon wird man auch Graphisch unterschiede merken.

Zitat:

Delphi hat eigentlich von den Mängeln der MFC gelebt und war hier eine hervorragende Alternative.
Heute ist dieser Vorsprung verspielt.
Die VCL ist in die Jahre gekommen und jede neue Delphiversion seit D5 bringt soviele Kinderkrankheiten und
Geburtswehen mit sich, das ein kommerzielles Arbeiten erst nach dem 2. Update sinnvoll ist.

Leider hat Kylix seine Wunden hinterlassen...

Zitat:

Delphi und Net ist auch nicht die erste Wahl.
Wenn ich Net 2.0 mit Delphi das erste mal ausprobiere, hat die Konkurenz schon ein Jahr Erfahrung.

Und durfte sich schon Wochenlang an Problemen von neuen Versionen herumplagen. Das war bisher bei Delphi kein Problem. Delphi kamm erst ca. 1 Jahr nach Win95, COM+ wurde erst 1 Jahr nach W2K unterstützt, ...

[Khabarakh]

Zitat von hanspeter:

Andre Heiljberg

Fast .

Zitat von peteress:

Zitat von Elvis:

• D.Net kennt keine namespaces.
  

• Das kann ja so nicht sein. Eine Sprache, die keine Namspaces kennt, könnte z.B. auf keine einzige FCL Klasse zugreifen.

• Hast du dir Delphi.NET überhaupt schonmal angeschaut? Die Sprache kennt keine Namespaces, nur der IL-Compiler muss es können.
  

  Zitat:

  Zitat von Elvis:

  Es ist sogar so fies, dass jede andere Sprache die namespaces deiner Packages sieht, nur du selbst musst dich weiterhin mit Units rumärgern.

• D.Net hat nur einen Single pass compiler der weiterhin absolute Eindeutigkeit von Bezeichnern erzwingt. Das widerspricht oftmals .Net allgemein anerkannten guidelines...

[sir-archimedes]

Wenn ich nun mit Delphi eine .NET-Anwendung schriebe - sollte ich dann besser auf die Winforms oder auf VCL.NET setzen? Mit VCL.NET habe ich den Eindruck, dass sich zu einer Win32-Anwendung herzlich wenig ändert. Winforms scheint mir sehr anders zu sein...

[EDIT:] Habe mich mal etwas schlau gemacht über die VCL.NET. Das Konzept kommt für mich keinesfalls in Frage. Also entweder Winforms oder Win32...[/EDIT]

Ich tendiere dazu, das Projekt noch als evtl. letztes Projekt mit Win32 zu machen - allerdings möchte ich natürlich RemObjects nicht erst für Delphi kaufen und danach wegschmeissen müssen. Da ist echt dann guter Rat teuer.

Weiß jemand, welche VS-Version man braucht, um den Funktionsumfang einer Delphi 2006-Professional-Version ungefähr zu erhalten? Ich habe zumindest gesehen, dass man mit VS-Express bereits Datenbankanwendungen und so programmieren kann. Etwas, das ich unter den kostenlosen Delphi-Versionen stark vermisst habe.

[Elvis]

Zitat von peteress:

Zitat von Elvis:

• D.Net kennt keine namespaces.

Das kann ja so nicht sein. Eine Sprache, die keine Namspaces kennt, könnte z.B. auf keine einzige FCL Klasse zugreifen.

Ich glaube du hast mich hier absichtlich nicht verstanden.
Nehmen wir als Vergleich mal Chrome. Namespaces und ein multi pass compiler machen dich unabhängig von Dateigrenzen. Willst du einen Typen in eine andere Datei packen, mache es einfach:

Delphi-Quellcode:

namespace SomeNamespace;
interface
type
  Class1 = class
    property Value : Class2;
  end;
implementation
end;

Delphi-Quellcode:

namespace SomeNamespace;
interface
type
  Class2 = class
    property Value : Class1;
  end;
implementation
end;

Zitat:

Was also fehlt dir am Konzept der Namespaces?

Am Konzept nix, ich liebe namespaces.
Wieviel Arbeit gesteckt D.Net wurde nur damit du weiterhin "uses DeinNamespace.Unitname" tippen musst, während alle anderen Sprachen deine Assembly mit uses DeinNamespace nutzen können, ist doch wirklich erstaunlich...

Zitat:

Innerhalb der Regeln für die Sprache, muß der Compiler natürlich eindeutig feststellen können, welcher Bezeichner denn eigentlich gemeint ist. Das hat auch eindeutig nichts mit dem Single oder Multipass Compiler zu tun.

Richtig, dafür muss der Compiler nur schlau genug sein. Suche einfach mal DialogResult.
Andere .Net-Komposter erkennen einfach wann etwas ein Typ sein _muss_ und wann der Bezeichner eine Variable/Property ist.
Solche Dinge hat man in .Net alle paar Minuten, schlichtweg weil es dort normal ist, Property und Typ gleich zu benennen. Es ist schon sehr nervig ständig typen aliase oder den kompletten Pfad zum Typen tippen zu müssen.
Oh und ich sage ja auch nicht, dass man nicht in den Himmel kommt, wenn man D.Net benutzt. Es ist einfach nur so, dass die meisten .Net Sprachen das haben, was D32 von anderen nativen Sprachen unterschied. Nur wurden sie weiterentwickelt und auf .Net getrimmt. Wie man sicherlich herauslesen kann, kann nur ein Delphi Fan so enttäuscht über D.Net sein.

Zitat:

Weiß jemand, welche VS-Version man braucht, um den Funktionsumfang einer Delphi 2006-Professional-Version ungefähr zu erhalten?

Kommt darauf an, was du tatsächlich benutzt. Kann sein, dass du mit einer 300€ Standard auskommst.

[peteress]

Also halten wir fest:

Delphi beherrscht Namespaces, macht diese aber nicht von Dateigrenzen unabhängig. Ich wäre als Projektleiter, deseen Existenz von Dingen wie Qualität, Wartbarkeit des erzeugten Codes abhängt, und der Vorhersagbarkeit von Kosten abhängt nicht so sicher, ob ich über die Form von Disziplin, die Delphi hier erzwingt, nicht doch eher glücklich sein sollte.

Dasgleiche gilt für die Verwendung von Schlüsselwörtern als Bezeichner. Es ist die Aufgabe, moderner Compiler nicht alles zuzulassen, was machbar ist. Das dürfte C# im Vergleich zu C++ ganz deutlich zeigen. Ob die Verwendung von Schlüsselwörtern als Bezeichner nicht aus gutem Grund verweigert wird, nämlich um den Pascalguidelines folgend, Wert auf die Lesbarkeit des Codes zu legen, muss dann halt jeder Entscheider, der die Kosten seiner Entscheidung verantworten muss, selber entscheiden.

Soweit das aufgrund der Sprachunabhängigkeit von .Net nowendig ist, kann Delphi aber sehr wohl Schlüsselwörter als Bezeichner verwenden.
Die .Net Guidelines werden damit doch erfüllt.

Zitat:

Erweiterte Bezeichner

Besonders bei der Programmierung in Delphi für .NET könnten Sie auf Bezeichner (z.B. Typen oder Methoden in Klassen) stoßen, die denselben Namen wie ein Delphi-Schlüsselwort haben. Eine Klasse könnte z.B. eine Methode mit dem Namen begin haben. Ein weiteres Beispiel ist die CLR-Klasse System.Type im Namespace System. Type ist ein Delphi-Schlüsselwort und darf nicht als Name für einen Bezeichner verwendet werden.
Wenn Sie den Bezeichner mit der vollständigen Namespace-Spezifikation qualifizieren, dann besteht kein Problem. Um beispielsweise die Klasse System.Type einzusetzen, müssen Sie ihren voll qualifizierten Namen angeben:
var
TMyType : System.Type; // Der voll qualifizierte Namespace wird verwendet, um
// die Doppeldeutigkeit mit dem Delphi-Schlüsselwort auszuschließen.
Der Ampersandoperator (&) kann als eine kürzere Alternative zum Auflösen der Doppeldeutigkeit zwischen Bezeichnern und Delphi-Schlüsselwörtern verwendet werden. Wenn Sie auf eine Methode oder einen Typ mit demselben Namen wie ein Delphi-Schlüsselwort stoßen, können Sie die Namespace-Spezifikation weglassen. Sie müssen dann aber dem Bezeichnernamen ein Ampersand voranstellen. Im folgenden Code wird z.B. ein Ampersand zur Unterscheidung der CLR-Klasse System.Type von dem Delphi-Schlüsselwort type verwendet.
var
TMyType : &Type; // Präfix '&' ist ok.

[peteress]

Ach ja

Zitat von Elvis:

Das hat auch eindeutig nichts mit dem Single oder Multipass Compiler zu tun.]Richtig, dafür muss der Compiler nur schlau genug sein. Suche einfach mal DialogResult.
Andere .Net-Komposter erkennen einfach wann etwas ein Typ sein _muss_ und wann der Bezeichner eine Variable/Property ist.
Solche Dinge hat man in .Net alle paar Minuten, schlichtweg weil es dort normal ist, Property und Typ gleich zu benennen. Es ist schon sehr nervig ständig typen aliase oder den kompletten Pfad zum Typen tippen zu müssen.

Das ist das Konzept einzelner Sprachen, und um welchen Preis.

Sind Konstrukte wie

Zitat:

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
...

private System.ComponentModel.IContainer components;
private System.Windows.Forms.MainMenu mainMenu1;
private System.Windows.Forms.MenuItem menuItemFile;
private System.Windows.Forms.MenuItem menuItemNew;

nicht fürchterlich?
Der Compiler erkennt das Schlüsselwot doch nur weil es in jeder Zeile wiederholt wird (Aufbau der Zeile). Das spart weder Tipparbeit, noch macht es den Code lesbarer.
Wenn es nicht jetzt schon in den entsprechenden Codeguidelines steht, so wird man in Kürze darin finden, das man dieses Feature nur verwenden sollte, wenn es sich nicht vermeiden lässt

Ein recht hoher Preis, nur dafür begin als Methodennamen verwenden zu können.

Grüße
Peter

[Elvis]

Sorry, aber was ist dein Punkt? Niemand sprach von Keywords.
Das DialogResult-Problem liegt schlichtweg darin, dass ein Form eine Property namens DialogResult hat, welche vom Typ DialogResult ist.
Wenn man jetzt diesen setzen oder das Ergebnis eines Dialoges prüfen will kapiert D.Net nicht wann die Property und wann der Typ gemeint ist. DialogResult.OK ist aber nur auf den Typen des Enums anwendbar so dass es keine Verwirrung geben _sollte_. Da es ein sehr vertändlicher Name für propertx und Typ ist, sehe ich hier keinerlei Probleme aus deinem puristischen POV.

Mit deinem letzten Post packe ich dich mal in die Schublade "romantischer Die-hard", ohne die wäre die IT-Branche wohl um einiges langweiliger. (Nicht böse gemeint )

[peteress]

Zitat von Elvis:

Sorry, aber was ist dein Punkt? Niemand sprach von Keywords.

Das Codesnipsel von K... sah für mich so aus, als sei dieser Punkt gemeint.

Zitat von Elvis:

Das DialogResult-Problem liegt schlichtweg darin, dass ein Form eine Property namens DialogResult hat, welche vom Typ DialogResult ist.
Wenn man jetzt diesen setzen oder das Ergebnis eines Dialoges prüfen will kapiert D.Net nicht wann die Property und wann der Typ gemeint ist.

Das ist so nicht richtig. Delphi läßt aus gutem Grund die Namnesgleichheit von Typen und Membern nicht zu, kann aber damit umgehen, dass andere .Net Sprachen das zulassen. Was bei Delphi (noch?) nicht so elegant gelöst ist, ist der import von namespaces. Lass bei CSharp mal die Importklausel weg, dann verhält es sich hier genauso wie Delphi, insbeondere auf die Qualifizierung von Dialogresult. Also, die Namnesräume werden bei Delphi nicht automatisch aufgelöst, auch wenn er in der Usesklausel erwähnt wurde. Das ist ein Manko, aber ein verschmerzbares.

Zitat von Elvis:

DialogResult.OK ist aber nur auf den Typen des Enums anwendbar so dass es keine Verwirrung geben _sollte_. Da es ein sehr vertändlicher Name für propertx und Typ ist, sehe ich hier keinerlei Probleme aus deinem puristischen POV.

DAs hat mit Purismus nichts zu tun, sondern es geht darum, warum Projekte scheitern und Budgets überzogen werden. Die wichtigen Gründe dafür sind die Lesbarkeit des Codes. Es geht nicht darum, den einen Buchstaben bei TDialogresult zu tippen, sondern darum, was verwirrt einen zukünftigen Leser des Codes weniger. Der CEO der OMG hat da mal die Klasse der sogenannten "write only" Sprachen eingeführt. Warum machen wir uns denn die Mühe, Componenten von Button1 nach btnOK umzubenennen, und uns dafür Konventionen auszudenken, an die sich dann jeder halten soll, und niemand tut, wenn er nicht gezwungen wird.
Entscheidend für die Kosten ist eben nicht, was kann man ein wenig schneller tippen, sondern was kann ein anderer später schneller lesen, und was kann ein Mensch schneller lernen zu lesen.

Zitat von Elvis:

Mit deinem letzten Post packe ich dich mal in die Schublade "romantischer Die-hard", ohne die wäre die IT-Branche wohl um einiges langweiliger. (Nicht böse gemeint )

Ich bin schon ein romantischer Typ, aber nicht in Bezug auf IT. Hier geht es um Kosten. Meine Prognose, statistische Untersuchungen würden ergeben, daß ein Quelltext, bei dem alle Typen durch ein T am Anfang markiert wurden, von Testprobanden schneller gelesen wird, als einer, bei dem Member und Typen gleich benamst werden.