Форум: "Потрепаться";
Текущий архив: 2002.06.03;
Скачать: [xml.tar.bz2];
ВнизНовое в UBPFD Найти похожие ветки
← →
VID (2002-04-21 21:43) [0]Итак, возникла новая идея: наряду с добавлением в UBPFD таких типов кода (программных единиц, что ли :) ) как function, procedure, intermediate, добавить также возможность добавления целых юнитов (unit).
Это я к тому, что иногда конечному пользователю, бывает проще целый unit с этой базы стянуть, нежели всё составляющие функции. Да и отправить иногда проще целый юнит, чем отправлять отдельно составляющие функции, и в каждой указывать зависимости и источник данных (то бишь, пример использования для каждой функции).
НО ЮНИТЫ МОЖНО ОТПРАВЛЯТЬ ТОЛЬКО ПРИ УСЛОВИИ ЧТО ЭТОТ ЮНИТ БУДЕТ РЕШАТЬ КОНКРЕТНУЮ ЗАДАЧУ, а не являтся копилкой всякого добра :)
А если Ваша функция будет использовать (зависеть) от какого-нибудь юнита в UBPFD, то эту зависимость (в строке зависимостей формы отправки кода) можно указать так : unit UBPFD.SomeUnitName
что скажите ?
← →
lipskiy (2002-04-21 21:56) [1]Лично я против такого расширения, по крайней мере - сейчас.
Этак можно дойти и до компонент.
Ничего плохого в этом, конечно, нет, но на первом этапе нужно наладить систему на мелкообъемных единицах.
И если все заработает и будет пользоваться спросом - тогда можно думать и о более крупных программных единицах.
К тому же надо еще подумать о работе модераторов/мастеров, согласятся ли они проделывать такой титанический труд, как тестировать целые юниты?
← →
vuk (2002-04-21 23:10) [2]А я за. Объясню почему. Дело в том, что у меня, например, не так много (я бы даже сказал достаточно мало) отдельных функций, поскольку я связанные вещи предпочитаю оформлять в виде классов...
← →
VID (2002-04-22 22:26) [3]А что думают остальные ?
← →
Oleg_Gashev (2002-04-23 01:22) [4]С отдельными функциями далеко не уедишь. Некоторые задачи удобнее решать в виде раделения кода на несколько задач, оформляя все в виде функций. Все это, естественно, удобно выложить в виде отдельного unit.
Например. У меня есть алгоритм Optimizing, method Nelder (deforming polyhedron), содержащий довольно большое количество констант, типов и 22 функций. Выкладывать их по отдельности бессмыслено.
← →
Sergo (2002-04-23 07:46) [5]Я за, но если главные "рулевые" говорят, что надо немного подождать, то можно и подождать :))
← →
Malder (2002-04-23 12:36) [6]Ха-ха. Вы натыкаетесь на проблему о которой я говорил раньше. Отдельно, сами по себе, процедуры и функции не будут делать ничего особо полезного. Нужны юниты или компоненты...
Вы подумайте, наберете вы столько много отдельных функций и процедур, что они будут полезны народу ?
← →
lipskiy (2002-04-23 16:55) [7]Ладно, похоже большинство правы, надо и юниты позволить добавлять. Убедили :)
← →
Malder (2002-04-23 17:28) [8]Вот вот вот. А потом вы точно решите, что и компоненты стоит добавлять. А то зачем куча юнитов, если можно один компонент ?
А кто проверять будет ? Хех. Знаете что вы делаете ? Новый www.torry.com
← →
VID (2002-04-23 19:01) [9]To Malder:
Интересно, где же это ты Университет Волшебства, пророческий факультет заканчивал ? :) Почему-то кажется, что ты всё-таки против UBPFD...
Почему мы должны переходить к компонентам ?
В UBPFD будут отдельные функции, которые прекрасно будут обходятся без специальных для них юнитов, и эти функции можно будет использовать без проблем. Юниты нужны для более сложный функций. На юнитах можно и остановится...
ОСНОВНАЯ ОРИЕНТАЦИЯ UBPFD - КОД, то что можно вырезать и вставить в текстовый редактор, а не квадратики-компоненты...
В компонентах бывает 1 нужная и 10 ненужных функций, за которые приходится платить размером проги (размер всё ещё имеет значение :) )
PS: а вообще сделать новый torry - это же круто ! :)
Страницы: 1 вся ветка
Форум: "Потрепаться";
Текущий архив: 2002.06.03;
Скачать: [xml.tar.bz2];
Память: 0.46 MB
Время: 0.005 c