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

[GrayEddy]

Имеются в виду packages, ну как в Delphi.
думаю, многим это интересно узнать.

[Максим]

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

[Bupyc]

GrayEddy, по большому счёту, большой ли в них смысл? Один из проектов, которыми я занимался, был полностью построен на bpl-пакетах. Т.е. в проекте было системное ядро, которое использовалось везде и набор функционала, который опционально добавлялся, если в этом была необходимость. Ядро и весь остальной функционал были оформлены в виде bpl. Когда у меня зародилась идея перенести проект на Windows CE, я стал анализировать, какую среду разработки для этого выбрать. Одним из критериев выбора, была поддержка пакетов в каком бы то ни было виде. Наиболее подходящим вариантом, сначала был Borland Developer Studio с какими то плагинами, позволяющими компилить под compact framework. Однако, позднее у меня сложилось ощущение, что кода, сложнее "Hello world" я там всё таки не получу. Поразмыслив, я решил, что для меня не будет критичным, если я буду компилить модули из пакетов в единый EXE-шник. Поэтому я остановил свой выбор на FPC, даже не смотря на то, что поддержки пакетов в нём нет.

[vital]

GrayEddy, по большому счёту, большой ли в них смысл?

Большой. Пока их поддержки нет, Lazarus так и будет оставаться одним большим костылём. Собственно говоря, пакеты - одна из ключевых фич компилятора Delphi, которая как раз и позволила создать такую качественную VCL и, соответственно, RAD IDE.

P.S. Кстати, как без пакетов Вы представляете себе будущее Lazarus-программ на мобильных устройствах? Да и в целом, принимая во внимание монстрообразность библиотек лазаря?
"Нет сынок, это фантастика"(с):)

[vital]

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

Патчи чего?

P.S. Вы лично контактируете с разработчиками FPC?

[Bupyc]

vital, я не спорю. Было бы лучше, если бы поддержка bpl или каких то аналогов была реализована в fpc. Но на мой неправильный субъективный взгляд, это не самая критичная проблема. При большом желании модульную разработку, основанную на bpl всегда можно перекомпоновать в единый ехе-шник, который будет работать точно так же, как и программа, состоящая из кучи пакетов.

P.S. Кстати, как без пакетов Вы представляете себе будущее Lazarus-программ на мобильных устройствах? Да и в целом, принимая во внимание монстрообразность библиотек лазаря?

Без пакетов, как то еще могу представить, а вот без библиотеки отлаженных визуальных компонентов представляю очень слабо. А LCL для win ce на сегодняшний день весьма и весьма нестабильна. Это, как мне кажется, намного большая проблема, чем поддержка динамических пакетов.

[Slavikk]

я тут недавно думал над этим вопросом, необходимо было в *.dll использовать LCL, т.е. попросту форма из *.dll. Нашёл только одно и достаточно кодоёмкое решение. В dll хранятся данные по которым прямо во время работы программы динамически создаются самой программой компоненты (формы и кнопки), а обработку событий созданных кнопок обрабатывает *.dll. Но по существу это псевдо LCL в *.dll - попросту файл по которому подымается дизайн + обычная dll. Но этого хватает заглаза.

[vital]

я тут недавно думал над этим вопросом, необходимо было в *.dll использовать LCL, т.е. попросту форма из *.dll. Нашёл только одно и достаточно кодоёмкое решение. В dll хранятся данные по которым прямо во время работы программы динамически создаются самой программой компоненты (формы и кнопки), а обработку событий созданных кнопок обрабатывает *.dll. Но по существу это псевдо LCL в *.dll - попросту файл по которому подымается дизайн + обычная dll. Но этого хватает заглаза.

Может вот это пригодится?:
http://www.delphisources.ru/pages/faq/b ... n_dll.html

[Slavikk]

Неа, это не делфя, здесь такое не прокатит. Здесь программа и *.dll абсолюто автономны и по памяти и по rtl, поэтому я и делаю меж ними общение на основе интерфейсов и функций.

[Максим]

Патчи чего?

Патчи, реализующие поддержку пакетов.

P.S. Вы лично контактируете с разработчиками FPC?

Я контактирую с ними через списки рассылки и чат, так же, как и все другие желающие
Эта тема неоднократно обсуждалась в списке рассылки fpc-devel.

Кстати, как без пакетов Вы представляете себе будущее Lazarus-программ на мобильных устройствах? Да и в целом, принимая во внимание монстрообразность библиотек лазаря?

А как пакеты помогут решить эту проблему

[vital]

Патчи чего?

1. Патчи, реализующие поддержку пакетов.

Кстати, как без пакетов Вы представляете себе будущее Lazarus-программ на мобильных устройствах? Да и в целом, принимая во внимание монстрообразность библиотек лазаря?

2. А как пакеты помогут решить эту проблему

1. "Патчи" - это ещё мягко говоря. Потребуется много дорабатывать компилятор напильником(возможно, и линкер тоже). Думаю, кроме авторов сделать это квалифицированно больше некому(нет, можно, конечно, убив кучу времени сесть за исходники компилятора и выдать что-то в итоге, но весь вопрос в целесообразности). Просто у авторов, судя по всему, не очень чёткое понимание перспектив развития своего детища. А перспектива, имхо, одна - достижение максимальной совместимости со стандартом де-факто промышленного Pascal-программирования(Delphi, вестимо). Без этого, Free Pascal , будет если и не мёртв, то гм... в медицине это называется "стабильно тяжёлым состоянием". И все эти увлечения такими "фичами", как перегрузка операторов и макросы в С-стиле на фоне отсутствия такого базового функционала Delphi, как поддержки пакетов, порой неудовлетворительной совместимости даже по библиотекам RTL(не далее как вчера столкнулся: реализация передачи в функцию открытого массива констант работает несколько по-другому) только ведут в тупик(Лазарь там находится уже давно, и судя по всему, так и останется вечной бетой )

2. Помогут избежать ненужного дублирования кода. Сейчас Лазарь линкует "пакеты" статически и приходится тащить всё добро с собой, теперь представьте, что на мобильном устройстве стоит несколько Lazarus-программ и каждая содержит в себе жирный кусок одного и того же кода. Возможности сделать в этом случае своего рода фреймворк, используемый всеми этими программами и экономящий ресурсы нет в принципе А говорите при чём тут пакеты...

[Deepthroat]

Неа, это не делфя, здесь такое не прокатит. Здесь программа и *.dll абсолюто автономны и по памяти и по rtl, поэтому я и делаю меж ними общение на основе интерфейсов и функций.

Ну в приведенной ссылке так и есть. Весь функционал формы в dll, а из программы только вызываются функции CreateTheForm, LoadTheForm, ReadTheForm, ShowTheForm, DestroyTheForm для создания, удаления и пр. Все автономно, а как иначе?

[Максим]

Просто у авторов, судя по всему, не очень чёткое понимание перспектив развития своего детища. А перспектива, имхо, одна - достижение максимальной совместимости со стандартом де-факто промышленного Pascal-программирования(Delphi, вестимо).

На мой вкус понимание у них вполне чёткое. И проблеме совместимости с Delphi уделяется много внимания. При этом надо понимать, что 100% совместимости достичь очень сложно, в частности, в связи с кросс-платформенностью FPC/Lazarus. Плюс надо учитывать, что ряд возможностей, например, перегрузка функций и операторов, в FPC появился раньше, чем в Delphi.

Без этого, Free Pascal , будет если и не мёртв, то гм... в медицине это называется "стабильно тяжёлым состоянием". И все эти увлечения такими "фичами", как перегрузка операторов и макросы в С-стиле на фоне отсутствия такого базового функционала Delphi, как поддержки пакетов, порой неудовлетворительной совместимости даже по библиотекам RTL(не далее как вчера столкнулся: реализация передачи в функцию открытого массива констант работает несколько по-другому) только ведут в тупик(Лазарь там находится уже давно, и судя по всему, так и останется вечной бетой )

Как я уже писал выше, совместимость очень неплоха, и постоянно улучшается. Если вы обнаружили несовместимости с Delphi, сообщите о них в багтрекер.

Lazarus, кстати, развивается хорошими темпами, и уже сейчас IMHO вполне пригоден для работы.

Помогут избежать ненужного дублирования кода. Сейчас Лазарь линкует "пакеты" статически и приходится тащить всё добро с собой, теперь представьте, что на мобильном устройстве стоит несколько Lazarus-программ и каждая содержит в себе жирный кусок одного и того же кода. Возможности сделать в этом случае своего рода фреймворк, используемый всеми этими программами и экономящий ресурсы нет в принципе А говорите при чём тут пакеты...

А вы учитываете, что при использовании пакетов у вас:

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

:?:

Мне лично не очень понятно, зачем это всё нужно, если только код программы не закрыт.

Вот последний тред с обсуждением этого вопроса в списке рассылки.

[alexs]

в) Появляется проблема DLL Hell

На мой взгляд, это это одна из самых главных проблем и дельфи и вобще винды - очень большая бочка дёгтя в сторону пакетов. Особенно это будет заметно в FPC, где сам компилятор не стоит на месте и каждый день дорабатывается, соответсвенно будут меняться и пакеты.

[vital]

в) Появляется проблема DLL Hell

На мой взгляд, это это одна из самых главных проблем и дельфи и вобще винды - очень большая бочка дёгтя в сторону пакетов. Особенно это будет заметно в FPC, где сам компилятор не стоит на месте и каждый день дорабатывается, соответсвенно будут меняться и пакеты.

dll-hell - это боян времён Win9x. Начиная с Win2k эта проблема решена. Эпизодические упоминания её исходят от самой Microsoft как рекламный слоган при продвижении .NET. И не более того.

P.S. Проблема rpm-hell встречается гораздо чаще, я бы сказал, несравнимо чаще.