Когда появятся пакеты?

[vital]

Вообще, главная фишка пакетов - это отсутствие проблемы корректной идентификации классов при передаче ссылки на объект через границу библиотеки. Т.е. is и as работают корректно. Ну и решение проблем управления памятью(передача строк и других указателей) - это вторая фишка.
Ну раз разработчики не хотят заниматься рассматриваемым вопросом, то смысла в обсуждении, действительно, нет. Жираф большой, ему видней...

P.S. Пересборка Лазаря при установке/удалении пакетов - это каменный век.

[Максим]

Вообще, главная фишка пакетов - это отсутствие проблемы корректной идентификации классов при передаче ссылки на объект через границу библиотеки. Т.е. is и as работают корректно. Ну и решение проблем управления памятью(передача строк и других указателей) - это вторая фишка.

Я полностью согласен. Просто, на мой взгляд, пакеты больше создают проблем, чем решают. Так что возможность эта полезна, но IMHO не является самой приоритетной.

P.S. Пересборка Лазаря при установке/удалении пакетов - это каменный век.

Не вижу различий с Delphi с точки зрения пользователя. Какая разница, что там происходит внутри?

Кстати, вполне возможно, что в следующей версии Lazarus'а отпадёт необходимость в компиляции IDE при установке пакетов, и останется только компиляция собственно пакета и его линковка с IDE. Так что упадёт и время установки.

[debi12345]

а) Смартлинк идёт лесом => увеличивается совокупный размер программы и требуемых ей библиотек (например, становятся нужны RTL, FCL, LCL в полном объёме);
б) Имеет место некоторое падение производительности;
в) Появляется проблема DLL Hell, так как для каждой версии FPC и Lazarus библиотеки будут разными => проблема с обновлениями вашей программы.

Чтобы увидеть явления во всей красе, доведем ситуацию до абсолюта (типа, на ФПК написаны все приложения ) - например, представим вынь32 или линукс вообще без ДЛЛ, с полным смартилинком, максимальной производительностью, без хэлла. Сколько бы весили дистрибутивы, а ? Или МСОффис ?

ПС:

Тема БПЛ для встроенных устройств более чем актуальна, или придется на ФПК писать всю миниоперационку ( или как минимум всю ГУЙ-оболочку) плюс приложения как части этой операционки (чтобы общий код подгружался только один раз - при старте "операционки" ).
( тема уже всплывала в ньюс-конференции МСЕгуй - сразу после запуска первой кросскомпилированной программы под АРМ-устройством. Экономия места на флэше и памяти - здесь самое главное )

[alexs]

Боян?
Пример - программа налоговой отчётности, написана средстави от MS. Ну нафиге в ней модули gdiplus.dll, msvcr70.dll?
И это не считая бесчисленных ocx.

Примеров множество.
И нынешняя ситуация в програмерском мире такова в винде, что основная масса сидит на си. Надежды на то, что леминги массово мигрируют на fpc - нет. Спрашивается - где экономия места из-за применения пакетов?

Единственный плюс - рассылка обновлений. Но он проявляется, когда среда разработки устоявшаяся, не меняется.
В данный момент это не относится ни к FPC, ни к Lazarus. Буквально сегодня в очередной раз команда fpc увеличила версию ppu-шек. Старые уже не совместимы с сегодняшним компилятором.
Так что - пакеты в данный момент не самая главная необходимость в fpc.

На мой взгляд - важнее встроенный линкер для платформ, отличных от винды.

[Deepthroat]

Тема БПЛ для встроенных устройств более чем актуальна

А чем разделяемые библиотеки не устраивают?

[debi12345]

А чем разделяемые библиотеки не устраивают?
==========
Тем, что не позволяют хранить формы. Там еще много нюансов с управленим памятью, временем жизни объектов,..

БПЛ = ДЛЛ, заточенные для хранения форм.

[vital]

А чем разделяемые библиотеки не устраивают?
==========
Тем, что не позволяют хранить формы. Там еще много нюансов с управленим памятью, временем жизни объектов,..

БПЛ = ДЛЛ, заточенные для хранения форм.

Правка: БПЛ = ДЛЛ спец. вида, заточенные для хранения экземпляров классов(объектов). Формы - лишь частный случай, не всё в этом мире сводится к рисованию интерфейса.