Delphi .NET Facts - was sich ändert

[sakura]

Hi DPler,

für alle die unter Euch, welche über den aktuellen Delphi-Tellerrand schauen möchten, hier mal eine vorläufige Liste der Dinge, welche mit Delphi.NET aus der Delphi Language verschwinden werden oder welche sich ändern. Diese Liste entstammt dem Buch Mastering Delphi 7 von Marco Cantù.

Deprecated Typen

• Pointer gelten als veraltet. Diese werden unter Umständen noch unterstützt, aber über kurz oder lang verschwinden. Pointer gelten unter .NET als unsafe Types, da deren Typ nicht überprüft werden kann. Pointer-Arithmetik ist verboten.
• file of <type> wird nicht mehr unterstützt, da die Record-Größe abhängig von der Zielplattform sein kann.
• Das Schlüsselwort object, welches bis lang noch unterstützt wurde, wird komplett gestrichen - es bleibt nur noch class.
• Real48 und Comp werden verschwinden. Comp wird dabei durch Int64 ersetzt.

Basis-Typenänderungen

• String ist in Zukunft ein WideString (16 Bit/Char), nicht mehr AnsiString (8 Bit). String wird auf System.String gemappt. Entsprechend wird Char zu WideChar (16 Bit) anstatt AnsiChar (8 Bit).
• Records werden als "Value Types" gewertet. (Hm, keine Ahnung, wie das zu verstehen ist :roll:) Neu ist, das Records in Zukunft auch Methoden deklarieren können. Diese müssen als final (neu!) deklariert werden. Vererbung von Records ist weiterhin nicht möglich - es gibt ja Klassen ;-)
• TDateTime erhält ein neues Format, entsprechend dem .NET System.DateTime. Achtung!, bei allen Umstellungen. Der neue Typ kann Daten vom 01.01.01 00:00:00 bis zum einschließlich 31.12.9999 11:59:00 aufnehmen.
• Currency wird auf den Typen System.Decimal gemappt - wird also nicht mehr direkt unterstützt.

Deprecated Code Anweisungen

• Variant Records werden nicht mehr unterstützt, da Typen-Größen Plattformabhängig sind.
• Der Pointer ExitProc wird nicht mehr unterstützt. Es muss auf initialization und finalization ausgewichen werden!
• Die dynamische Einbindung von Interfaces via implements wird nicht mehr unterstützt. Argh, habe ich gerade erst kennen und lieben gelernt :roll:
• Assembler Anweisungen werden nicht mehr unterstützt, da diese Plattform-Abhängig sind.
• Die Schlüsselwörter automated und dispid entfallen, da diese durch die .NET Struktur nicht mehr benötigt werden.
• Direkter Zugriff auf Speicher durch Methoden wie BlockRead, BlockWrite, GetMem, FreeMem und ReAllocMem sind nicht mehr möglich.
• Der @-Operator wird vermutlich verschwinden

Also, wer will, kann auch schon jetzt auf diese Änderungen achten, dann wird die Umsetzung unter .NET einfacher ;-)

...:cat:...

[Hansa]

Da werden diejenigen schwer schuften müssen, die hardwarenah programmieren, mit Pointern auf Hardware-Adressen etc. zugreifen, oder knallhart den Speicher selber verwalten mit GetMem usw. :mrgreen: Dasselbe gilt für ASM Befehle. Da das vor allem unter C++ sehr beliebt ist, können die sich warm anziehen. Ich glaube Delphi macht da wesentlich weniger Probleme.

Mir ist das sowieso egal, weil solche Programmiertechniken nur Fehler produzieren (Bluescreens kommen viel durch so was), benutze ich das alles nicht. Das mit dem "FILE OF ..." gefällt mir weniger. Das braucht man schon mal.

Meine schlimmste Befürchtung ist aber, daß in irgendeinem Programm in Zeile 1166 der Compiler streikt und keiner weiß (zumindest vorerst) warum, bzw. was wie anders gemacht werden muß. 8)

Trotzdem ist keine Panik angesagt, die werden schon einigermaßen wissen, wo die Knackpunkte liegen und dementsprechend für Alternativen Sorgen.

P.S.: jetzt habe ich die Frage vergessen: Du schreibst string wäre ein WideString, was ist das im Moment wenn man

Zitat:

VAR st : string

schreibt ? Bzw. für die neuen Typendefinitionen (Datum ja auch), was sollte man da jetzt nehmen, um später nichts verändern zu müssen ?

[Christian Seehase]

Moin sakura,

soll das alles eigentlich für Delphi Language oder Delphi Language for .NET gelten?

[sakura]

Zitat:

Zitat von Hansa

Bzw. für die neuen Typendefinitionen (Datum ja auch), was sollte man da jetzt nehmen, um später nichts verändern zu müssen ?

Für den String gilt, entweder Du deklarierst den als AnsiString (aktuelle Implementation von String) oder als WideString, die zukünftige Implementation.

Bei TDateTime wird es eine Menge Handarbeit, leider :wall: Da hilft nichts drumrum...

...:cat:...

[sakura]

Zitat:

Zitat von Christian Seehase

soll das alles eigentlich für Delphi Language oder Delphi Language for .NET gelten?

Ich denke mal für beide, da kleinere Änderungen bereits jetzt in Delphi 7 vorhanden sind. Für Kylix gilt ja auch die gleiche Sprache.

...:cat:...

[Christian Seehase]

Moin sakura,

ich dachte nur daran, dass man im Visual Studio ja mit C# arbeiten kann, bei dem halt gewisse Einschränkungen gegeben sind, oder mit C++ wo das dann nicht der Fall ist.
Man kann ja, wenn auch mit gewissen Verrenkungen, unter C# ganz normal die API Funktionen importieren und damit arbeiten, und die sich ja nicht gerade pointerlos.

[Chewie]

Zitat:

Zitat von Sakura

Das Schlüsselwort object, welches bis lang noch unterstützt wurde, wird komplett gestrichen - es bleibt nur noch object.

Ist das ein Schreibfehler oder raff ichs einfach nicht?
Ich denke, so sollte es heißen:

Zitat:

Das Schlüsselwort object, welches bis lang noch unterstützt wurde, wird komplett gestrichen - es bleibt nur noch class

[Hansa]

Zitat:

Zitat von sakura

Bei TDateTime wird es eine Menge Handarbeit, leider :wall: Da hilft nichts drumrum...

Wollen die etwa einen neuen Date-Typ bringen, den es noch nicht gibt ? :evil: Na ja, ^QA gibts ja auch noch. Und ich habe vor längerer Zeit mal ein Programm gebastelt, daß den Quelltext nach einem Wort durchsucht und durch ein anderes ersetzt. Anscheinend muß man zu solch rabiaten Mitteln greifen. :spin:

Leider weiß ich den Grund nicht mehr, warum ich ein "^QA" Programm geschrieben habe, hört sich trotzdem langsam nach schlechtem Film an. Vieles wird anders oder entfällt, aber nun die entscheidende Frage: Was ist der Vorteil von dem Firlefanz :?:

[sakura]

Zitat:

Zitat von Chewie

Ist das ein Schreibfehler oder raff ichs einfach nicht?
Ich denke, so sollte es heißen:

Zitat:

Das Schlüsselwort object, welches bis lang noch unterstützt wurde, wird komplett gestrichen - es bleibt nur noch class

*Asche auf mein Haupt* Danke, ich habe es im Original korrigiert. :oops:

...:cat:...

[sakura]

Zitat:

Zitat von Hansa

Wollen die etwa einen neuen Date-Typ bringen, den es noch nicht gibt ? :evil:

^QA wird Dir leider nicht viel helfen, da der neue Datentyp und der alte Datentyp den gleichen Namen haben, aber leider verschiedenen implementiert sind. Wer aber fleißig die DateTime-Funktionen genutzt hat, der sollte i.A. keine Probleme bekommen, allerdings dürften diejenigen, welche z.B. mit Int und Frac gearbeitet haben leichte Schwierigkeiten bekommen. Näheres schreibe ich, sobald ich es weiß.

...:cat:...

[Hansa]

Also wird das wohl so laufen, wie mit dem alten String, der jetzt ein ShortString ist. Dann würde ^QA doch helfen, string würde durch ShortString ersetzt und alles wäre kompatibel. 8) Sieht trotzdewm schwer nach "Try and error" aus. Na ja, abwarten und Tee trinken.

[mirage228]

Zitat:

Zitat von sakura

Pointer gelten als veraltet. Diese werden unter Umständen noch unterstützt, aber über kurz oder lang verschwinden. Pointer gelten unter .NET als unsafe Types, da deren Typ nicht überprüft werden kann. Pointer-Arithmetik ist verboten.

dabei wollte ich gerade mit Pointern anfangen... und wodurch werden Pointer dann ersetzt? Gar nicht?

Zitat:

file of <type wird nicht mehr unterstützt, da die Record-Größe abhängig von der Zielplattform sein kann.

Hab ich sowieso net gebraucht, aber ich kenn genug Leute dies vermissen werden!

Zitat:

[*]Das Schlüsselwort object, welches bis lang noch unterstützt wurde, wird komplett gestrichen - es bleibt nur noch class.

Argh, das ist Ärgerlich, denn ich benutze gerne "Object". Was ist denn so schlimm an Object?

Zitat:

String ist in Zukunft ein WideString (16 Bit/Char), nicht mehr AnsiString (8 Bit). String wird auf System.String gemappt. Entsprechend wird Char zu WideChar (16 Bit) anstatt AnsiChar (8 Bit).

Hört sich ganz sinvoll an ;-)

Zitat:

Der Pointer ExitProc wird nicht mehr unterstützt. Es muss auf initialization und finalization ausgewichen werden!

Was hat der nochmal bewirkt??

Zitat:

Die dynamische Einbindung von Interfaces via implements wird nicht mehr unterstützt. Argh, habe ich gerade erst kennen und lieben gelernt :roll:

Wolltes selber noch lernen...

Zitat:

Assembler Anweisungen werden nicht mehr unterstützt, da diese Plattform-Abhängig sind.

Also ich finde Assembler manchmal schon notwendig, besonders wenn es ganz ganz schnell gehen soll. Was wohl mein Kumpel dazu sagt, der gerade Assembler lern :roll:

Zitat:

Direkter Zugriff auf Speicher durch Methoden wie BlockRead, BlockWrite, GetMem, FreeMem und ReAllocMem sind nicht mehr möglich.
Der @-Operator wird vermutlich verschwinden

Erstes: Naja, ich Kopiere Dateien sowieo nur noch per CopyFile oder mit Streams. Ansonsten hab ich die besagten Methoden nicht so oft benutzt.
Zweites: Was kommt dan anstelle des @ ??

Zitat:

Also, wer will, kann auch schon jetzt auf diese Änderungen achten, dann wird die Umsetzung unter .NET einfacher ;-)

Vielleicht werde ich ja fertig, bis Delphi .NET rauskommt.

Amen.

mirage228

[Daniel B]

Hallo,

Zitat:

Zitat von mirage228

Argh, das ist Ärgerlich, denn ich benutze gerne "Object". Was ist denn so schlimm an Object?

KOP hört sich schöner und "wichtiger" an als OOP?! :mrgreen:

Grüsse, Daniel :hi:

[S - tefano]

Hi,

wo außer im Zusammenhang mit Pointern wird denn in Delphi noch der @-Operator verwendet?
Wenner wirklich nur bei Pointern verwendet wird, ist es dann nicht logisch dass er mit den Pointern verschwindet?
Die Dinger (also die Pointer, nie die "@"s) konnt ich eh nie leiden...
Aber file of <type> und BlockRead/-Write werden mir fehlen. Muss man dann komplett auf FileStreams oder die ShellBefehle umsteigen?
Was mal recht interessant werden kann, sind die Methoden in Records. Haben die vielleicht deswegen die file of <type> abgeschafft, damit man das "Abspeichern von Methoden" umgehen kann? Naja, bezweifle ich mal.
Aber ich würd ja gerne wissen...
wo liegt denn dann der Unterschied zwischen einem Record und einer Klasse / einem Objekt?
Muss man dann wirklich jeden blöden String als WideString deklarieren? Wenn der normale String in seiner "Beschaffenheit" doch sowieso abgeschafft wird (wird er das?), könnte man nicht einfach nen neuen String- Typen unter demselben Namen einführen?
Is doch irgendwie schöner, oder?

Bis dann,

S - tefano

[Chewie]

Alles geraten, also kein Gewähr!

Zitat:

Zitat von S - tefano

Was mal recht interessant werden kann, sind die Methoden in Records. Haben die vielleicht deswegen die file of <type> abgeschafft, damit man das "Abspeichern von Methoden" umgehen kann? Naja, bezweifle ich mal.
Aber ich würd ja gerne wissen...
wo liegt denn dann der Unterschied zwischen einem Record und einer Klasse / einem Objekt?

Man kann Records ja auch mit einem Stream speichern. Der Unterschied zwischen Records und Klassen war ja vorher, abgesehen von den Methoden, der, dass ein Record ja quasi ein Speicherblock war, während eine Klasse wegen den Methoden verschiedene Zeiger beinhaltet hat. Vielleicht wird das ja fortgeführt, die Methoden in einem Record sind auch im Speicherbereich des Records enthalten.

Zitat:

Zitat von S - tefano

Muss man dann wirklich jeden blöden String als WideString deklarieren? Wenn der normale String in seiner "Beschaffenheit" doch sowieso abgeschafft wird (wird er das?), könnte man nicht einfach nen neuen String- Typen unter demselben Namen einführen?

Aber nein, es wird weiterhin AnsiString und AnsiChar geben. Genauso, wie es wohl WideString und WideChar weiter geben wird. Während es bisher so war, dass String gleich AnsiString ist, wird in Zukunft String gleich WideString sein.

[Daniel B]

Hallo,

Zitat:

Zitat von Chewie

Aber nein, es wird weiterhin AnsiString und AnsiChar geben. Genauso, wie es wohl WideString und WideChar weiter geben wird. Während es bisher so war, dass String gleich AnsiString ist, wird in Zukunft String gleich WideString sein.

Eins ist mir aber doch nicht wirklich Klar. Ein String wird zu WideString. Also schriebt man(n) "var s: WideString;" oder doch nur String und das wird "intern" geregelt!?
Und wenn man WideString schreiben muss, wer schriebt als erster im Forum ein Tool, das alle .pas auf dem Rechner durchgeht und String in WideString umschreibt? :mrgreen: :lol:

Grüsse, Daniel :hi:

[Christian Seehase]

Moin Daniel,

Du kannst heute in den Optionen einstellen, wie "string" interpretiert werden soll.
Entweder als HugeString (AnsiString, Standard) oder ShortString (Pascal String).

Künfig wird unter string standardmässige WideString verstanden, und die Optionen werden einem dann eventuell die Wahl zwischen drei Varianten lassen.

[Hansa]

Zitat:

Zitat von Chewie

wird in Zukunft String gleich WideString sein.

vermutlich kommen da noch einige Compiler-Direktiven dazu und dann hats sich.

[sakura]

Zitat:

Zitat von Hansa

vermutlich kommen da noch einige Compiler-Direktiven dazu und dann hats sich.

Ja und nein. Was es die Assemblies betrifft, sind die wohl alle auf WideStrings ausgelegt und dann heisst es wieder vorsicht bei der Nutzung der Assemblies. Und solange es nicht um gesicherte Daten alter Programme geht, ist es auch nicht weiter dramatisch.

...:cat:...

P.S. Ich nutze schon jetzt WideStrings :mrgreen:

[neolithos]

Kann mir einer sagen wie ich OHNE Zeiger
- einen Binären-Such-Baum aufbauen soll
- verkettete Listen verwalten soll
- große Variable Binär-Blöcke verwalten soll (z.B. von Bildern)


Ich denke das .NET zusätzlich wie CLX entstehen wird, denn wie soll ich sonst Windows beeinflussen.

Denn das Importieren von nicht .NET-Dll's ist nicht sauber und nicht Plattformunabhängig.

[EnORItZ]

Also zu den Objekten, z.B. können die ja so aussehen

Delphi-Quellcode:

type
 TMeinObjekt = Object
  eigenschaft1 : string;
  procedure Hallo(var i,a,b: integer);
 end;

Jetzt wird aber das Object selbst wegfallen, allerdings hab ich gehört das man sowas wie dort oben auch mit Records realisierbar sein soll(Also Methoden z.B.).

Also so:

Delphi-Quellcode:

type
 TMeinObjekt = Record
  Eigenschaft1: string;
  procedure Hallo(var i,a,b: integer);
 end;

vorher wars ja nur möglich Prozeduren so in Records einzubauen:

Delphi-Quellcode:

type
 TMeinRecord = Record
  eigenschaft1: string;
  Hallo: Procedure(var i,a,b: integer);
 end;

Korrigiert mich bitte wenn ich da was falsches sage.

Ich glaub das stand sogar in Ausgabe 4.2003 von Der Entwickler

/Edit:

Zitat:

Records werden als "Value Types" gewertet. (Hm, keine Ahnung, wie das zu verstehen ist ) Neu ist, das Records in Zukunft auch Methoden deklarieren können. Diese müssen als final (neu!) deklariert werden. Vererbung von Records ist weiterhin nicht möglich - es gibt ja Klassen

Sorry das hab ich zu spät gesehn

[sakura]

Kein Problem. ;-) Zum Thema object vs. class. Object kommt noch aus Turbo Pascal Zeiten (seit Version 5.5) und wird von Delphi nur aus Gründen der Kompatibilität unterstützt. Seit Version 1 von Delphi sollte man für alle neuen Klassen (und Objekte) mit class arbeiten.

...:cat:...

[Tool-Box]

Hallo Sakura,

Ich bin am Überlegen von Turbo Pascal 7.0 auf Delphi 8 umzusteigen.

Ich habe gelesen, dass auf der Delphi 8 (octane) auch die Delphi 7 Version beigelegt sein soll. Weisst du, ob auch Kylix 3 mit enthalten sein wird ?

Desweiteren habe ich hier irgendwo gelesen, dass unter Delphi.Net der Befehl "File of..." nicht mehr unterstützt werden soll.

Wie müsste untengenannter Record aus Pascal in Delphi umgeschrieben werden ?


Bsp.

Delphi-Quellcode:

Type Datenbank_Spiel_77 = Record (* Super 6 - Nr. 1 *) 
Nr : LongInt; 
Ziehung_I : Integer; 
Ziehung_S : String[7]; 
Datum : String[10]; 
Ziehungstag : String[2]; 
Ziehungsmonat : String[2]; 
Ziehungsjahr : String[4]; 
Spiel : String[8]; 
Spieltag : String[10]; 
S1 : Byte; 
S2 : Byte; 
S3 : Byte; 
S4 : Byte; 
S5 : Byte; 
S6 : Byte; 
S7 : Byte; 
end; 
Filetyp_2 = File of Datenbank_Spiel_77;

Danke im voraus für evtl. Info.

Gruss, Tool-Box :)

[edit=sakura]Delphi-TAGs eingefügt. Mfg, sakura[/edit]

[sakura]

Zitat:

Zitat von Tool-Box

Ich habe gelesen, dass auf der Delphi 8 (octane) auch die Delphi 7 Version beigelegt sein soll. Weisst du, ob auch Kylix 3 mit enthalten sein wird ?

Da kann auch ich nur sagen: Mal bei Borland anrufen...

Die liebe Frau am Borland-Telefon sagte unverbindlich

Prinzipiell wird Kylix nicht zusammen mit Delphi 8 (Octane) ausgeliefert. Es wird zur Zeit jedoch darüber seniert, ob es unter Umständen eine Promotionaktion geben wird, zu welcher während der Einführung Kylix enthalten ist.

Zitat:

Zitat von Tool-Box

Desweiteren habe ich hier irgendwo gelesen, dass unter Delphi.Net der Befehl "File of..." nicht mehr unterstützt werden soll.

Wie müsste untengenannter Record aus Pascal in Delphi umgeschrieben werden ?

Das wirst Du am Besten komplett auf Streams ausweichen - sollte man schon jetzt tun, wenn es geht ;-) Mit obiger Type-Strukture sähe es dann wie folgend aus:

Delphi-Quellcode:

var
  DbEntry: Datenbank_Spiel_77;
  FS: TFileStream;
begin
  // Datei öffnen
  FS := TFileStream.Create('data.file', fmOpenReadWrite or fmShareDenyNone);
  try
    // read 3 data entry
    FS.Position := SizeOf(Datenbank_Spiel_77) * (3 - 1);
    FS.Read(DbEntry, SizeOf(Datenbank_Spiel_77));

    ...


    // save at first position
    FS.Position := 0;
    FS.Write(DbEntry, SizeOf(Datenbank_Spiel_77));
  finally
    // Datei schließen
    FS.Free;
  end;

...:cat:...

[Wormid]

Zwei Dinge:

1) Wie sieht es denn in Zukunft mit der nonVCL - Programmierung aus, wenn Zeiger, und Low-Level-Speicherverwaltung (GetMem, FreeMem, etc...) nicht mehr benutzt werden dürfen?

2)Wird es denn noch Befehle wie "LoadLibrary" und "GetProcAddress" geben? Ich meine, wenn Sie alles ausmerzen, was eine Plattformabhängigkeit schaffen könnte, dann gehört sowas doch leider auch dazu...
Es wäre IMHO ein herber tiefschlag für Delphi, wenn man auf einmal keine der teilweise recht genialen, frei verfügbaren DLLs diverser Projekte nutzen könnte (libmysql.dll, bass.dll.. usw und so fort!)

Gruß

Wormid

[Chewie]

Soweit ich weiß lassen sich mit .NET Dlls einbinden, allerdings nur sehr aufwändig. Wenn du DLLs benutzen musst, kannst du aber auch eine native Win32 (bzw. bald Win64??)-Anwendung erstellen.

[sakura]

Zitat:

Zitat von Wormid

1) Wie sieht es denn in Zukunft mit der nonVCL - Programmierung aus, wenn Zeiger, und Low-Level-Speicherverwaltung (GetMem, FreeMem, etc...) nicht mehr benutzt werden dürfen?

Vorläufig gibt es ja noch Win32 - allerdings widersprechen diese Art der Anwendungen dem "Sicherheitskonzept" von .NET. Keine Ahnung wie es in ein paar Jahren damit aussieht.

Zitat:

Zitat von Wormid

2)Wird es denn noch Befehle wie "LoadLibrary" und "GetProcAddress" geben? Ich meine, wenn Sie alles ausmerzen, was eine Plattformabhängigkeit schaffen könnte, dann gehört sowas doch leider auch dazu...

DLLs wird man noch laden können. Wie weiß ich noch nicht, aber das sollte nicht das eigentliche Problem sein. Aber auch hier gilt gleiches wie oben, wenn es mal eine reine .NET Plattform geben wird, dann wird es auch hier nur noch Assemblies geben und DLLs sind wahrscheinlich. ein Teil der grausigen Vergangenheit. (Letzteres beruht jetzt aber nur auf theoretisch hergeleitetem Wissen und nicht auf basierten Kenntnissen.)

...:cat:...

[Ghostwalker]

hmmmm...sieht auf den ersten blick nicht tragisch aus. Nur... .NET ist ja (genaugenommen) platform abhängig, da es nur unter Win verfügbar ist (und ich nicht glaube das M$ hier nen Port auf Linux macht.. :mrgreen:). und somit stellt sich mir die frage was der Quark eigentlich soll ?

[Jens Schumann]

Hallo

Zitat:

und ich nicht glaube das M$ hier nen Port auf Linux macht

Dafür gibt ja das Mono Projekt

[Pseudemys Nelsoni]

irgendwie hört sich das .NET zeug mehr wien nachteil als vorteil an? oder täuscht das?

[Christian Seehase]

Moin Silent,

ich würde das mal als Ansichtssache sehen.
Ein Vorteil wäre, dass Du einzelne Module (Assemblys) verwenden kannst, ohne, dass Du Dich darum kümmern musst, in welcher .NET Sprache sie erstellt wurden. Ob diese mit C#, VB.NET oder z.B. Delphi.NET erstellt wurden, darf keine Rolle spielen.
Die Idee mit der Plattformunabhängigkeit ist ja gut und schön, aber ich vermute mal, bevor das greifen kann existieren schon so viele plattformabhängige Programme, dass das schön daneben geht ;-)

[neolithos]

Zitat:

Zitat von Christian Seehase

Die Idee mit der Plattformunabhängigkeit ist ja gut und schön, aber ich vermute mal, bevor das greifen kann existieren schon so viele plattformabhängige Programme, dass das schön daneben geht

So wie derzeit von der Importmöglichkeit in den Assemblys im Internet gebrauch gemacht wird. Stimmt das schon!
Darum sehe ich noch keinen Sinn zu wechseln, da sowas viel besser noch mit einem Win32-Programm geht.

Zitat:

Zitat von Christian Seehase

Ein Vorteil wäre, dass Du einzelne Module (Assemblys) verwenden kannst, ohne, dass Du Dich darum kümmern musst, in welcher .NET Sprache sie erstellt wurden. Ob diese mit C#, VB.NET oder z.B. Delphi.NET erstellt wurden, darf keine Rolle spielen.

War das bei ActiveX bzw. der Dll-Technologie nicht genauso gedacht? Und ist dann durch sprachspezifsche Sachen (wie Export von Klassen) wieder eingeschränkt wurden.

Ich finde man versucht da auf brechen und biegen eine Neuerung den Leuten zu verkaufen, die noch nicht durchdacht ist.

Bis jetzt findet sich .NET meiner Meinung nach im Teststatium.

-> Man sollte sich damit Beschäftigen aber noch warten! Was nun entgültig herauskommt.

[maximov]

Hätte da auch noch zwei, für mich interssante, fragen:

Wird es RTTI einträge für records geben?
Wird die RTTI auch parameterlisten der published methoden geben?

mfg. maximov.