|
Registriert seit: 18. Aug 2004
Ort: Brackenheim VS08 Pro
2.876 Beiträge
|
Re: Delphi für .NET <> Delphi Win32
17. Jan 2006, 17:05
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...
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  . Member mit gleichem Namen, deren Scopes sich nicht überschneiden, ist natürlich auch in Delphi möglich. Aber so etwas wie
ist in anderen .NET-Sprachen problemlos möglich und oft ziemlich nützlich.
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? Ok, du hast dir Delphi.NET wirklich noch nie angeschaut . 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;
}
}
Sebastian
Moderator in der EE
|
|
|
Zitat
|