Wie zukunftssicher ist das BPL Konzept?

[QuickAndDirty]

Hallo, wie gefährlich ist es
wenn ich mich davon abhängig mache das es das BPLs immer in Delphi geben wird?

Z.Z. implementiere ich alles in DLLs und BPLs obwohl ich bei DLLs dafür schmutzige
Tricks(Typecasting &c. ) anwenden muss. Einfach weil ich mir nicht sicher war das es BPLs ewig geben wird,
weil es ja nichts von von Microsoft unterstütztes ist.

Irgendwie macht mir das doppelte halten der Projekte (DLL und BPL) langsam keinen Spaß mehr.

Wie zukunftssicher ist das BPL Konzept ?

[mkinzler]

Die Befürchtung, dass EM dieses Konzept fallen lässt hätte ich nicht. Möglicherweise wird es irgendwann nicht mehr gepflegt aber entfernen werden sie dieses Feature sicherlich nicht.

[himitsu]

Sieht es nur so aus oder nutzt Emba nicht selber an vielen Stellen BPLs?

Dann würden die sich ja selber in Fleisch schneiden, wenn sie es einfach so abschaffen.


PS: Delphi schleppt viele "Altlasten" mit sich rum, darum ist es ja zu großen Teilen so schön abwärtskompatibel.
z.B. die ShortStrings

[Bernhard Geyer]

Wenn es BPL nicht mehr gibt dann gibt es auch kein Delphi mehr.
BPL sind ja nur DLL's mit erweiterten Features (gemeinsame Objekhierarchie, ...)

[QuickAndDirty]

Ja genau diese Features sind es, von denen ich wissen will ob ich mich auf deren Existenz in der fernen Zuknunft auch noch verlassen kann.

Immerhin beabsichtige gerade quasi die ganze Firma davon abhängig zu machen das es die BPL Features immer geben wird.

[Insider2004]

F+r eigene Programme würde ich nie DLL oder BPLs nehmen. Das Konzept ist einfach zu anfällig für Fehler, wenn man beim Kunden ist. Vor allem, wenn andere die gesharten DLLs de-installieren oder updaten etc...

[Astat]

Zitat von QuickAndDirty:

Ja genau diese Features sind es, von denen ich wissen will ob ich mich auf deren Existenz in der fernen Zuknunft auch noch verlassen kann.

Immerhin beabsichtige gerade quasi die ganze Firma davon abhängig zu machen das es die BPL Features immer geben wird.

Hallo QuickAndDirty, Pascal ist als Programmiersprache noch nicht mal zertifiziert.
Es gibt allerlei Wildwuchs (FPC, Delphi 2-2007, Delphi 2009 - 2010) alle mit unterschiedlichen Spracherweiterungen und Sprachfeatures. 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. Dies kann auch in zukünftigen EMBA-usw. Releases auch wieder vorkommen.
Aus dieser Sicht betrachtet, kann ich DLL's die Win32 API-Konform entwickelt wurden, egal welcher Pascal Dialekt, weiterhin verwenden. Natürlich auch nur solange, bis Microsoft die Win32 - API dicht macht. Inwieweit da die Gefahr besteht, kann ich nicht beurteilen. Sicher ist jedoch, dass die MS'ler nur noch .NET - API verwenden möchten.

lg. Astat

[hanspeter]

Zitat von Astat:

Hallo QuickAndDirty, Es gibt allerlei Wildwuchs (FPC, Delphi 2-2007, Delphi 2009 - 2010) alle mit unterschiedlichen Spracherweiterungen und Sprachfeatures. Wenn wir nun mal bei Delphi bleiben, so können BPL's die die neuen Sprachfeatures von 2009 - 2010 verwenden

lg. Astat

Ich halte die bpl für einen großen Designfehler in Delphi. Gut gemeint aber nicht mehr zeitgemäß. BPL sind nur gegen die gleiche Compilerversion und den gleichen Compilierungsstand der Umgebung compatibel.
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.
Wenn man zukunftssicher sein will und bei Pascal bleiben will, dann ist wohl Delphi prism die tragfähigere Variante.
32 bit ist längerfristig eine aussterbende Plattform und 64 bit ist bei Delphi noch in weiter Ferne.
Erst kommt wohl mal ein neuer Compiler. Und bis da die Kinderkrankheiten raus sind...

Gruß
Peter

[Bernhard Geyer]

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.

[QuickAndDirty]

Nun, wir haben ja den Quellcode unserer eigenen BPLs und es ist auch OK wenn wir die genauso wie alle Programme unseres Produkts bei jeder Gott verdammten Änderung in der IDE neu übersetzen oder anpassen müssen.

Wichtig ist nur das nicht morgen einer sagt: "ätsch gemeinsame RTTI und Speicherreferenzen zwischen BPL und Anwendung gibts nicht mehr."

Ich will meine Delphi Strings, dyn Arrays und Obkjekte IMMER in eine BPL übergeben können und daraus heraus.

Die Frage ist also nicht wie Scheiße/Gut ist das BPL Konzept, sondern wie sehr kann ich mich auf die EWIGE Unterstützung dieses Konzepts verlassen?