Zitat von
Astat:
Wenn wir nun mal bei Delphi bleiben, so können
BPL's die die neuen Sprachfeatures von 2009 - 2010 verwenden
nicht mehr von älteren Versionen verwendet werden.
BPL können nicht mal verwendet werden wenn der Compiler/Klassnbibliothek ein SP erhält. Dafür ist es auch nicht vorgesehen.
schon mal probiert eine .NET 1.1 Assembly in .NET 2.0 zu laden?
Aber für solche Austauschbarkeit wurde es nicht entwickelt.
Zitat von
Astat:
Natürlich auch nur solange, bis Microsoft die
Win32 -
API dicht macht.
Also so in 15-20 Jahren
Zitat von
Astat:
Inwieweit da die Gefahr besteht, kann ich nicht beurteilen. Sicher ist jedoch, dass die MS'ler nur noch .NET -
API verwenden möchten
Genau deshalb gab es in Vista 0 .NET-
API's und in Win7 ähnlich viele. Die Ribbons sind mit Win7 als native
Win32/64-Controls ins
OS gewandert.
Zitat von
hanspeter:
Ich halte die
bpl für einen großen Designfehler in Delphi.
Designfehler nicht, jedoch nicht konsequent weitergedacht und immer noch auf dem Level von D3 mit all den mängeln.
Zitat von
hanspeter:
Gut gemeint aber nicht mehr zeitgemäß.
BPL sind nur gegen die gleiche Compilerversion und den gleichen Compilierungsstand der Umgebung compatibel.
Das ja. Nicht mehr Zeitgemäß. Aber mit den ganzen Borland-Schlipsträgern und den ganzen "eigentlich wollen wir nur PP-Folien verkaufen" Fehlentwicklung wurden viele Arbeiten nicht gemacht. Erst seit einiger Zeit versucht man einiges wieder aufzuholen (
Unicode, Generics, Reflection auf erweiterter
RTTI-Basis, ...)
Zitat von
hanspeter:
Die zukunftsicherste Lösung zur Modularisierung in Delphi sind nach meiner Meinung Module als out of process Server.
Hier bestehen keinerlei Abhängigkeiten zwischen Compilerversion oder Bibliothek. Diese Module können aus allen Programmiersprachen, die
Com unterstützen, verwendet werden.
Halte ich nichts davon. Wir sind froh das wir keine
COM-Komponente mehr im Basissystem haben. XCopy-Installation ist sooooo schön.