Delphi für .NET <> Delphi Win32

[sir-archimedes]

Hallo,

ich habe bislang alle meine Projekte mit Delphi für Win32 geschrieben. Nun überlege ich, ob ich ein neues Projekt direkt mit .NET entwickeln sollte.

Was für Vorteile hätte eine Entwicklung für .NET?

Als bislang größten Nachteil sehe ich einerseite das Fehlen einiger guter Tools/Libraries, wie der ReportBuilder und andererseits mein momentan recht geringer Kenntnisstand über .NET. Letzteres könnte ich natürlich durch Einarbeitung bald ausgleichen.

Grundsätzlich möchte ich die Dinge, die Borland mit ECOII einsetzt nicht nutzen (alleine schon, da mein D2006Pro da nicht alle Fähigkeiten hat). Daher sehe ich bislang noch keine große Motivation für mich .NET einzusetzen. Aber gute Argumente können das natürlich schnell ändern :-)

Gruß,
Dominik

[Bernhard Geyer]

Zitat:

Zitat von dominik.boehm

Als bislang größten Nachteil sehe ich einerseite das Fehlen einiger guter Tools/Libraries, wie der ReportBuilder

Es gibt genügend gute Biblitheken auch in .NET. Du kennst Sie nur nicht.

Zitat:

Zitat von dominik.boehm

Grundsätzlich möchte ich die Dinge, die Borland mit ECOII einsetzt nicht nutzen (alleine schon, da mein D2006Pro da nicht alle Fähigkeiten hat). Daher sehe ich bislang noch keine große Motivation für mich .NET einzusetzen. Aber gute Argumente können das natürlich schnell ändern :-)

Es gibt auch Alternativframeworks wie ECO III auch auf dem Markt. Jedoch ist die Frage ob die alle so mächtig sind.

Es kommt immer darauf an was du machen willst.


Überall lauffähig: Wird dann evtl. auch Java besser geeignet sein
Entwicklung PocketPC: Da gibts nur .NET
Lauffähig auch auf älteren PC: Würde ich Win32 bevorzugen, da nicht unbedingt alte Rechner .NET-Kompatible sein. Und wer will schon schuld sein wenn ein Rechner nicht mehr geht.
64-Bit lösung schnell nötig: .NET
Web-Lösung. ASP.NET ist hier sehr gut.

[sir-archimedes]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von dominik.boehm

Als bislang größten Nachteil sehe ich einerseite das Fehlen einiger guter Tools/Libraries, wie der ReportBuilder

Es gibt genügend gute Biblitheken auch in .NET. Du kennst Sie nur nicht.

Das stimmt natürlich - hatte nur dein Eindruck, dass es noch nicht so viel gibt. Und bislang weiß ich nur, dass eine erste Portierung von ReportBuilder auf .NET gescheitert ist... Aber ansonsten habe ich mich noch nicht so sehr mit den Komponenten für .NET beschäftigt.

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von dominik.boehm

Grundsätzlich möchte ich die Dinge, die Borland mit ECOII einsetzt nicht nutzen (alleine schon, da mein D2006Pro da nicht alle Fähigkeiten hat).

Es gibt auch Alternativframeworks wie ECO III auch auf dem Markt. Jedoch ist die Frage ob die alle so mächtig sind.

Habe mich da vertan - hatte ECO III mit ECO II verwechselt. Interessant fände ich hier die Möglichkeiten des Objekt-Relationalen Mappings, auf das ich schon lange gewartet habe. Allerdings kann das mein Delphi (da nur Pro.) nicht und eine größere Version sitzt zur Zeit einfach nicht drin.

Web-Anwendungen und Plattformunabhängigkeit ist bislang nicht relevant und wird wahrscheinlich (bei dem Projekt) auch längerfristig nicht benötigt.

Gibt es denn ansonsten gute Gründe es mit .NET und nicht mit Win32 zu machen? (Plane zur Zeit auch die Anschaffung von RemObjects/DataAbstract und dafür muss ich natürlich auch wissen, ob ich .NET einsetzen möchte).

Achja: lässt sich nicht das .NET-Framework auf quasi allen zur Zeit gängigen Windowsplattformen installieren? Denn dann werden ja auch ältere Rechner unterstützt...

[DelphiAndreas]

ich würd von .net die Finger lasse wenn du auf die "Vorteile" verzichten kannst die Bernhard genannt hat. Ich glaube das .net-Framework gibts erst ab Win98SE, Win32 läuft ja praktisch überall.

Wenns wirklich Plattformunabhängig sein soll wäre wohl wirklich Java das beste, habe da recht gute Erfahrungen gemacht.

[Elvis]

Ich kann generell empfehlen neue Projekte nur in .Net zu beginnen. Natürlich nur solange das auch sinnvoll ist. (Wird z.Bsp.: viel direkter Speicherzugriff benötigt macht .Net wenig bis keinen Sinn...)

ORPFs für .Net gibt es wie Sand am Meer (nHibernate, nDO, OpenACCESS oder nHibernate-basierte Lösungen wie ActiveRecord).

Nur kann ich es nicht wirklich empfehlen dabei auf Delphi.Net zu setzen:

• D.Net kennt keine namespaces.
  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...
• Es wird Dinge an deine Klassen hängen, die sie aussehen lassen wie D32 Klassen.
  IMHO ein totales no-go falls du APIs anbieten willst. (Sinnlose public member wirken einfach komisch...)
• D.Net hinkte bisher immer dem Rest hinterher (D2006 mit 1.1 erschien nachdem .Net 2.0 herausgekommen ist)

Mit Sprachen, die auf .Net maßgeschneidert wurden, lassen sich viele Dinge schneller und mit weiger Code lösen. (z.Bsp.: C# oder Chrome)

ReportBuilder gibt es einige, CrystalReports ist ganz nett.
Und .Net wird von MS ab Win2000 unterstützt. Es gibt eine Version für 98/NT4 aaber damit musste ich mich zum Glück nicht rumärgern...

Zu den Vorteilen von .Net gehören IMHO:

• Reflection
• Riesige BaseclassLibrary
  Man findet vieles bereits vorgefertigt in der FCL.
• Remoting/ASP.Net
• Interface basiertes DataBinding für GUIs.
  Man kann fast alles an ein Control binden, welche Interfaces man implementiert hat bestimmen wieweit diese Bindung geht.
• Sprachunabhängigkeit

[Bernhard Geyer]

Zitat:

Zitat von dominik.boehm

Achja: lässt sich nicht das .NET-Framework auf quasi allen zur Zeit gängigen Windowsplattformen installieren? Denn dann werden ja auch ältere Rechner unterstützt...

Nur ab W98 (SE) mit IE 5.01 und allen sonstigen für IE 5.01 nötigen Updates.
Teile von .NET 2.0 gibt es nur für XP/2003 (Avalon).

[sir-archimedes]

Hmm - ich denke ich werde dann wohl den Weg des geringsten Widerstandes gehen, und erst mal noch mit Win32 weitermachen. Ich glaube die Vorteile von .NET kämen bei dem Projekt nicht so sehr zum Tragen und wahrscheinlich fährt man auch mit Win32-Anwendungen noch relativ gut.

Ich habe einfach nicht die Zeit, mich in ein komplett anderes System einzuarbeiten. Das werde ich aber nachholen, sobald ich die Zeit dazu finde.

[dfried]

Zitat:

Zitat von dominik.boehm

Gibt es denn ansonsten gute Gründe es mit .NET und nicht mit Win32 zu machen? (Plane zur Zeit auch die Anschaffung von RemObjects/DataAbstract und dafür muss ich natürlich auch wissen, ob ich .NET einsetzen möchte).

Wenn du soweiso schon "planst" dieses Framework einzusetzen, dann lies dir doch mal noch den BLOG Eintrag zum Thema .net oder nicht .net durch.

[hanspeter]

Hallo,

ein neues Projekt würde ich nicht mehr auf W32/Delphi aufsetzen.

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 und
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.
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%.
Ich selbst entwickle kommerziell noch mit Delphi 32, sehe aber bei einer Reihe Firmen eine Absetzbewegung
in Richtung Net.

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.
Dann kommt aber meistens auch schon die neue Version mit neuen Problemen.
Mit Andre Heiljberg ist der geistige Vater von Delphi zu MS gewechselt.
Die Erfahrungen mit Delphi haben viele Konzepte in der Net Welt geprägt.
Bei Erfahrungen mit Deplhi ist der Einarbeitungsaufwand geringer, als wenn man von typischen MS-Sprachen kommt.

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.

Fazit.
Ich meine die Blütezeit von Delphi ist vorbei.
Ich selbst benötige es nur noch um Altprojekte zu pflegen.
Schaue hier aber auch schon in Richtung Chrome und C2 (ein Delphi -> C# Konverter.)

Gruß

Peter

[peteress]

Zitat:

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.
  z.B. VB
  imports System.Drawing
  C#
  using System.Drawing
  Delphi.Net
  uses System.Drawing
  
  Was also fehlt dir am Konzept der Namespaces?
  
  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...

  Bezeichner mussten in Delphi noch nie eindeutig sein. Ich kann in jeder Prozedur die Laufvariable der For Schliefe wieder i nennen, jede Klasse kann eine Methode execute haben, und selbst mehrere globale Variablen können dengleichen Namen haben. 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. Nicht eindeutige Bezeichner werden durch mehrmaliges parsen des Quellcodes nicht eindeutiger. Das ist wie die alte Laborregel: Dreimal abgeschntten und immer noch zu kurz.
  
  
  
  Zitat:

  Zitat von Elvis

  Es wird Dinge an deine Klassen hängen, die sie aussehen lassen wie D32 Klassen.
  IMHO ein totales no-go falls du APIs anbieten willst. (Sinnlose public member wirken einfach komisch...)

  D.Net hinkte bisher immer dem Rest hinterher (D2006 mit 1.1 erschien nachdem .Net 2.0 herausgekommen ist)

Zitat:

Zitat von Elvis

Mit Sprachen, die auf .Net maßgeschneidert wurden, lassen sich viele Dinge schneller und mit weiger Code lösen. (z.Bsp.: C# oder Chrome)

Dass Delphi beim Compilieren (oder wann?), an Klassen public Members ranhängt. die im Quellcode noch nicht da waren, würde mich auch überraschen. Wieder die Frage, was soll das sein?
MS hat über drei Jahre mit 1500 Entwicklern an der Version 2.0 von Dot Net gebaut,und auch den eigenen Compiler dafür erst im letzten Quartal released. Ich denke, da kann man Borland schon noch ein paar Monate Zeit geben.

Gruss
Peter

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

Zitat von hanspeter

Andre Heiljberg

Fast :wink: .

Zitat:

Zitat von peteress

Zitat:

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:

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

  Bezeichner mussten in Delphi noch nie eindeutig sein. Ich kann in jeder Prozedur die Laufvariable der For Schliefe wieder i nennen, jede Klasse kann eine Methode execute haben, und selbst mehrere globale Variablen können dengleichen Namen haben. 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. Nicht eindeutige Bezeichner werden durch mehrmaliges parsen des Quellcodes nicht eindeutiger. Das ist wie die alte Laborregel: Dreimal abgeschntten und immer noch zu kurz.

  Jetzt muss ich fragen, ob du dir überhaupt schonmal eine andere .NET-Sprache angeschaut hast :stupid: . Member mit gleichem Namen, deren Scopes sich nicht überschneiden, ist natürlich auch in Delphi möglich. Aber so etwas wie
  
  Code:

  public Type Type {...}

  ist in anderen .NET-Sprachen problemlos möglich und oft ziemlich nützlich.
  
  Zitat:

  Zitat:

  Zitat von Elvis

  Es wird Dinge an deine Klassen hängen, die sie aussehen lassen wie D32 Klassen.
  IMHO ein totales no-go falls du APIs anbieten willst. (Sinnlose public member wirken einfach komisch...)

  D.Net hinkte bisher immer dem Rest hinterher (D2006 mit 1.1 erschien nachdem .Net 2.0 herausgekommen ist)

Zitat:

Zitat:

Zitat von Elvis

Mit Sprachen, die auf .Net maßgeschneidert wurden, lassen sich viele Dinge schneller und mit weiger Code lösen. (z.Bsp.: C# oder Chrome)

Dass Delphi beim Compilieren (oder wann?), an Klassen public Members ranhängt. die im Quellcode noch nicht da waren, würde mich auch überraschen. Wieder die Frage, was soll das sein?

Ok, du hast dir Delphi.NET wirklich noch nie angeschaut :wink: . Frisch aus dem Reflector:

Code:

public class MyClass
{
      // Methods
      static MyClass();
      public MyClass();
      [TMethod(4)]
      public static Type ClassInfo(@MetaMyClass Self);
      [TMethod(4)]
      public static string ClassName(@MetaMyClass Self);
      [TMethod(4)]
      public static bool ClassNameIs(@MetaMyClass Self, [In] string Name);
      [return: TAliasType(typeof(@TClass))]
      [TMethod(4)]
      public static @TClass ClassParent(@MetaMyClass Self);
      [return: TAliasType(typeof(@TClass))]
      public @TClass ClassType();
      public void Dispatch(ref object Message);
      [TMethod(4)]
      public static void DoSomething(@MetaMyClass Self);
      public object FieldAddress([In] string AName);
      public void Free();
      [TMethod(4)]
      public static bool InheritsFrom(@MetaMyClass Self, @TClass AClass);
      [TMethod(4)]
      public static MemberInfo MethodAddress(@MetaMyClass Self, [In] string AName);
      [TMethod(4)]
      public static string MethodName(@MetaMyClass Self, MemberInfo ACode);

      // Nested Types
      [ComVisible(false), CLSCompliant(false)]
      public class @MetaMyClass : @TClass
      {
            // Methods
            static @MetaMyClass();
            public @MetaMyClass();
            public virtual object @Create();

            // Fields
            public static MyClass.@MetaMyClass @Instance;
      }
}

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

Zitat von peteress

Zitat:

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. :mrgreen:
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:

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:

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:

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:

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:

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.