Блог человека, который 18-ть лет программирует на Delphi. И 25 лет программирует вообще. VCL, UML, MDA, тесты. Это не "учебник", это - "заметки на полях".
Ну, может я не прав. Но. Run-time пакетами - я никогда не пользовался. Design-time - да - там есть масса фич/проблем. Но если уменьшаешь количество Design-time, то и количество пакетов снижается.
Я собственно - ЦЕЛЕНАПРАВЛЕННО двигался именно в этом направлении. От "программирования на формах" к "программированию на UML".
> Но! Ваша идея и реализация - конечно ХОРОША! Спасибо. =) Но не всё так хорошо, как хотелось бы.
> Но если уменьшаешь количество Design-time, то и количество пакетов снижается. Не совсем понял суть. Пакет - это логическая сущность предназначенная для того, чтобы собрать пачку .pas файлов, и компилировать её отдельно от проекта. Таких пакетов у меня на работе набралась пара сотен (включая сторонние либы). И вот, чтобы всё это добро корректно собиралось и в правильном порядке - и был создан Lazy Builder.
И идея тут не в том, чтобы установить что-то в IDE (это побочная функция), а в том, чтобы зависимости определялись автоматом, на основании содержимого .dpk файлов. А когда библиотека большая, да ещё и постоянно развивается - необходимость пересобрать всё возникает ох как часто. Даже после обновления какой-либо сторонней библиотеки приходится пересобирать всё, что от неё зависит.
"Программирование на формах" - чудесный способ прострелить себе ногу верёвкой достаточной длины. Но хорош для быстрого рисования GUI.
Программирование на UML в Delphi - интересно было бы почитать про такой опыт. Причём не столько о проектировании, сколько о сопровождении проекта. =)
>Ну вот в том, то и дело, что dpk я последовательно изживаю. И пересобирать - нечего. Я знаю только такие способы обойтись без dpk-шек: # включить все модули бывшие в пакетах в сам проект (опционально, отказаться от сторонних библиотек) # минимизировать количество dpk-шек. Объекдинить нескольких dpk в один.
Я всё "тупо" включаю проект (хотя не тупо конечно). И создаю всё что нужно в Run-Time. Я же говорю - "в обратном направлении от RAD". Просто у меня "RAD" - несколько другой - UML. Я правда уж лет 5-ть думаю - как их объединить в симбиоз. Пишу свою "рисовалку" UML для внедрения её в Delphi. Как плагина. В идеале. Но это - КРАЙНЕ нескоро. Может и не в этой жизни. Это - не работа. Это - "для души".
Привет!
ОтветитьУдалить> Я правда последнее время старался двигаться в сторону "обратную RAD".
И какая связь у Lazy Delphi Builder-а с RAD-ом? Мне правда интересно. =)
Ну, может я не прав. Но. Run-time пакетами - я никогда не пользовался. Design-time - да - там есть масса фич/проблем. Но если уменьшаешь количество Design-time, то и количество пакетов снижается.
ОтветитьУдалитьЯ собственно - ЦЕЛЕНАПРАВЛЕННО двигался именно в этом направлении. От "программирования на формах" к "программированию на UML".
Но! Ваша идея и реализация - конечно ХОРОША!
ОтветитьУдалить> Но! Ваша идея и реализация - конечно ХОРОША!
ОтветитьУдалитьСпасибо. =) Но не всё так хорошо, как хотелось бы.
> Но если уменьшаешь количество Design-time, то и количество пакетов снижается.
Не совсем понял суть. Пакет - это логическая сущность предназначенная для того, чтобы собрать пачку .pas файлов, и компилировать её отдельно от проекта. Таких пакетов у меня на работе набралась пара сотен (включая сторонние либы). И вот, чтобы всё это добро корректно собиралось и в правильном порядке - и был создан Lazy Builder.
И идея тут не в том, чтобы установить что-то в IDE (это побочная функция), а в том, чтобы зависимости определялись автоматом, на основании содержимого .dpk файлов. А когда библиотека большая, да ещё и постоянно развивается - необходимость пересобрать всё возникает ох как часто. Даже после обновления какой-либо сторонней библиотеки приходится пересобирать всё, что от неё зависит.
"Программирование на формах" - чудесный способ прострелить себе ногу верёвкой достаточной длины. Но хорош для быстрого рисования GUI.
Программирование на UML в Delphi - интересно было бы почитать про такой опыт. Причём не столько о проектировании, сколько о сопровождении проекта. =)
Ну вот в том, то и дело, что dpk я последовательно изживаю. И пересобирать - нечего.
ОтветитьУдалитьПро UML - обязательно со временем напишу.
Сопровождать - мне лично - только помогает.
А зависимости кстати - тоже из UML выводятся. Естественно тем, которые нарисованы.
>Ну вот в том, то и дело, что dpk я последовательно изживаю. И пересобирать - нечего.
ОтветитьУдалитьЯ знаю только такие способы обойтись без dpk-шек:
# включить все модули бывшие в пакетах в сам проект (опционально, отказаться от сторонних библиотек)
# минимизировать количество dpk-шек. Объекдинить нескольких dpk в один.
А как это у вас сделано?
Я всё "тупо" включаю проект (хотя не тупо конечно). И создаю всё что нужно в Run-Time. Я же говорю - "в обратном направлении от RAD". Просто у меня "RAD" - несколько другой - UML. Я правда уж лет 5-ть думаю - как их объединить в симбиоз. Пишу свою "рисовалку" UML для внедрения её в Delphi. Как плагина. В идеале. Но это - КРАЙНЕ нескоро. Может и не в этой жизни. Это - не работа. Это - "для души".
ОтветитьУдалить