Описание тега bpl

Delphi - это компонентная среда разработки для собственного диалекта языка Паскаль.
В отличие от своего конкурента Visual Basic, он мог "есть свою пищу" - создавать эти компоненты для расширения.

До 1996 года для их установки нужно было перекомпилировать часть IDE, аналогично установке в Lazarus/FCL IDE. Это привело к двум проблемам:

• Чем больше компонентов вы устанавливаете, тем тяжелее становится IDE, а у компьютеров тогда было значительно меньше памяти. Вы не можете расположить разные подмножества компонентов для каждого проекта.
• Если какой-то компонент оказался безжалостно сломанным и вылетел из строя IDE, перенастройка и восстановление его без компонента становится менее очевидной задачей без использования IDE.

Это также мало помогло в развертывании больших программ: нужно было либо развернуть большой монолитный EXE, который мог вызвать проблемы в ОС с 16-разрядным ядром (Windows 9x/ME), либо разработать традиционную Windows DLL, жертвуя всей безопасностью типов и сложными типами (передавая объекты и строки на границах EXE/DLL или DLL/DLL были бы чрезвычайно хрупкими, что практически невозможно для среднего программиста).

С выпуском Delphi 3 в 1997 году Borland представила определенный тип DLL, с принудительной безопасностью типов (зависимости кодируются во время компиляции и проверяются во время загрузки) и изменила одну букву: DLL -> DPL - Delphi Package Library.

В следующем году Borland C++ Builder 1 (со встроенным Delphi 3.5), и эти библиотеки были снова переименованы: DPL -> BPL - Borland Package Library.

BPL остается основой для компонентной RAD Studio Дизайн IDE до сегодняшнего дня.

Недостатки BPL:

• Увеличивает проблему "утечки реализации" в Turbo Pascal, исходные единицы которого были представлены до тенденции ООП. Это вынуждает использовать частные члены и типы данных (рабочие классы) в интерфейсе общедоступного модуля. Позже разработчик языка Delphi исправил проблему, представивpartial classesв C#, но в Delphi эта функция отсутствует. Поскольку BPL публикует всеinterface разделов всех включенных модулей, даже внутренних "рабочих" модулей, невозможно сделать стабильный содержащий API, и спагетти-зависимости могут легко произойти незамеченными.
• Поскольку каждый блок является общедоступным по определению и поскольку BPL может повторно использоваться другими приложениями, Smart Linkerпобежден. Если вам нужен только 1% библиотеки - вы либо переделываете ее, либо развертываете всю библиотеку с 99% slab. В монолитном режиме EXE компилятор будет записывать XRefs иSmart Linker устранит неиспользуемые 99% библиотеки.
• Это также означает, что у вас не может быть нескольких модулей с одинаковым именем, как в случае с библиотеками DLL. Это не большая проблема, но может быть неудобно.
• Это также означает, что если вы переделываете какой-либо класс, например добавляете новый внутренний метод (виртуальный или нет), подпись класса изменяется, и все зависимые BPL должны быть перекомпилированы и повторно развернуты. Это особенно раздражает, когда вам нужно какое-то исправление в стандартном RTL
• Если вы измените параметры или версию компилятора, это изменение повлияет на внутренние классы / функции ABI, и все зависимые пакеты должны быть перекомпилированы и повторно развернуты.