Wozu sind BPL Fies gut?

[idefix2]

Man braucht diese Package Libraries, um Komponenten in die IDE zu installieren. Haben die sonst noch einen anderen Sinn?
Hat es irgend einen Nutzen normale Units in BPL Dateien aufzunehmen?

Implizit werden ja manche Units in ein BPL-File eingeschlossen, die von den angegebenen Units verwendet werden. Kann das zu Versionskonflikten führen?

[nahpets]

Guckst Du z. B. hier:

https://www.thoughtco.com/bpl-vs-dll-1058181

http://www.delphipraxis.net/171762-h...-packages.html

[reaktor]

Wenn dein Projekt Komponenten aus diesem Package benutzt, dann werden diese mit reinkompiliert -> die .exe/.dll/.. wird größer. Wenn du im Projekt einstellst, dass es mit Laufzeitpackages kompiliert werden soll und die entsprechenden Packages angibst, ist die erzeugte Datei nicht so groß. Du musst dann allerdings die .bpl-Dateien mit ausliefern. BPL-Dateien kannst du mit DLLs vergleichen mit dem Unterschied, dass BPL-Dateien nur von Delphi-Anwendungen genutzt werden können.

[MichaelT]

Zitat von idefix2:

Man braucht diese Package Libraries, um Komponenten in die IDE zu installieren. Haben die sonst noch einen anderen Sinn?
Hat es irgend einen Nutzen normale Units in BPL Dateien aufzunehmen?

Implizit werden ja manche Units in ein BPL-File eingeschlossen, die von den angegebenen Units verwendet werden. Kann das zu Versionskonflikten führen?

Den Umweg um Komponenten in die IDE zu installieren musstest du früher nicht nehmen und doch gab es Packages.

Ein Package dient der Code Strukturierung. Zumal die Package Library andere Optionen bspw. bezüglich Compilierung bietet würde ich sagen sie ist doch eigenständig und nicht vom Projekt abhängig. Diese Eigenschaft erbt die Package Library eher über die Library.

unit - steht vermutlich für Compilation Unit des Compilers. Alles dahinter ist relativ dubios.

Ein Klasse ist kaum vergleichbar mit allem zuvor.

Die Packages kann man sich am PC bspw. unter Windows am besten Vorstellen mit Funktionen welche im COM Laufzeitsystem werden aktiviert. Das wäre noch der beste Vergleich zu Algol 68.

• Load Per Call
• Load Shared
• Load Per Runnable Program Unit (wie in Java )

Oder ähnlich wäre noch bei einem XYZModule in Delphi das Threadinverhalten einzustellen und das 'Betriebsystem' sorgt dafür, dass das Laden transparent vom aufrufenden Programm passiert.

Die Library hat der Sysadmin installiert und ein Aktennotiz in Umlauf gebraucht, dass die Library installiert ist oder von mir aus ein Statistik Package.

Das Model ist heute nicht mehr so relevant für ein Betriebssystem wie früher. 'C'/UNIX.

-- In SAP gibt es soetwas noch
Im SAP schreibst du nur Report. Dann machst du eine Programmprüfung (report) und am Ende aktivierst du das Programm. Das SAP System kompiliert das Programm.

Eine Funktion ist allein ein Konstrukt auf der Metadatenebene. Wenn die Funktion aufgerufen wird, dann wird ein Binding gemacht. Das Modul wird geladen in eine Laufzeitumgebung. Ein Package umfasst im Falle von ABAP Metadaten usw.

ABAP Package

In dem Sinne schlagt eine Delphi Package noch in die Richtung mit Bezug auf die IDE

[himitsu]

Ein Package ist praktich erstmal eine DLL, welche aber zusätzlich "automatisch" seine RTTI und andere globale Dinge shared.

Es ist somit praktisch wie ein "Teil einer EXE/DLL", aber kann einzeln ausgetauscht werden (so lange sich die Schnittstellen nicht ändern), bzw. von mehreren Programmen gemeinsam genutzt werden (wie eine DLL)

Ja, das kann man gut nutzen, um Komponenten in die IDE einzubinden, ohne gleich die ganze IDE neu kompilieren zu müssen.
Und dennoch hat man in der BPL auf alles Zugriff, was die IDE bietet und die IDE kennt auch die BPL (RTTI).
Also gemeinsame Verwendung des selben Speichermanagers, der System-Units und die Units der RTL/VCL/FMX usw. , inkl. deren globaler Variablen.

Bei einer DLL ist dagegen alles getrennt und man hat von der EXE aus nur Zugriff auf die DLL, aber die DLL keinen Zugriff auf die EXE.
Darum kann/darf man da auch keine Objekte durchreichen, da jeder seine eigene "Version" dieser Objekt-Klassen (RTTI, Definitionen, Methoden, ...) besitzt, die grundsätzlich nicht kompatibel sind, und standardmäßig auch einen getrennten Speicher (kein SharedMemory) haben.