гы-гы, долго бы смеялся, но возраст прошел уже.
Да и все благополучно забыто всеми высказавшимися сюда(не надолго IMHO).
Ценность этой(как и любой другой) темы в "осадке" т.е. в том что было сказано(спрошено,сделано) "по существу".
Хочу высказаться на первый пост ValeryW по поводу стиля исполнения GDL в общем и кол-ва параметров в частности.
В профессиональной среде программистов все не с бухты-барахты(если не брать российскую реальность - "лишь бы бабло срубить"),
как у нас всех - здесь высказавшихся. Наколеночников-любителей.
В GDL не бывает профессионалов. /@SergeyAB
Это не упрек, это реальность - никто из авторов не знаком с процессом профессиональной разработки кода.
По крайней мере ничего здравого об этой части не было, а ноги растут отсюда, ибо иначе получается спор о вкусах...
Это конечно великодушно со стороны графисофт, спасибо им за GDL, ну а в целом - подобная фича - "скриптить" присутствует в любом заслуживающем внимания приложении, вопрос к публике - программист на GDL?! Может в резюме указать и программистом идти устраиваться?
вкратце(много общего с разработкой ПСД, терминология условна):
1 этап. Обоснование инвестиций. Заказчик решает что ему нужно(на своем корявом "заказчиковом" языке).
2. этап. Спецификация продукта(согласование функционально-организационной формы продукты). Совместно с исполнителем. Первоначальный вариант, тут степень детализации зависит от квалификации программиста-исполнителя.
3. этап. Согласование РАЗРАБОТАННОГО ПРОГРАММИСТОМ техзадания на разработку с заказчиком.
4. этап. Утверждение ТЗ разработчиком.
5. Разработка "календарного плана"
6. Первые шаги по разработке.
Если согласовать и утвердить ТЗ, то вопроса о количестве параметров, и вообще интерфейсе, просто не возникнет.
А иначе будет воз и ныне там, когда сам себе ставишь задачу и решаешь ее - результат в любом случае будет прямо пропорционален степени косности ЛИЧНО ТВОЕГО мышления, и надо думать - понравится(не-) твоя работа людям с аналогичной(отличной) косностью мышления.
BeArt писал:
"Переходите на более высокий уровень программирования. Задайте себе вопрос: А достаточно ли я подкован для создания библиотечных элементов?"
Хотелось бы услышать ответ автора на свой вопрос
по-человечески интересно...
Еще вот че сказать хочется...в нашу "наколеночную" тему.
Есть такая наука эргономика, в которой опытно-экспериментальным путем определяются характеристики неживого так чтобы живому было удобно с неживым(кто сказал резиновая женщина?! Вон!!!).
Тут таже тема - интерфейс должен быть "доступным" для среднестатистического персонажа.
Не слишком умного, не слишком глупого, не слишком зеленого не слишком опытного, можно продолжать, это раз.
А во вторых если есть норматив регламентирующий объект то объект должен в строгости соответсвовать этому регламенту, чего нельзя сказать о пресловутой библиотеке Титова - это кубики для детской лепки не более того.
Как искать эту "середину" ...
Лично мое мнение такое:
все зависит от "специфики" объекта - существует ли общепринятая документация, терминология по теме(или на) данного(ый) объекта. Если да то объект отнесем к:
ГРУППА 1:
НАДО ИЗУЧАТЬ эту общепринятую информацию, ИБО не надо думать что мы первопроходцы - есть ГОСТы, СЕРИИ, техрегламенты, и протча, а вот косностью мышления и не знанием этих нормативов мы сведем на нет труд предыдущих поколений, точнее не сведем на нет а устроим "разночтение".Что не позволительно вообще-то.Т.е. правило - "строгое соблюдение того что есть и никакой отсебятины+страхование от человеческого фактора". Под страхованием подразумеваю невозможность задавать характеристики конструкций не представленные в ГОСТ.
ГРУППА 2: "модерновые светильники" и протча, тут уж о вкусах GDL можно спорить, но не стоит забывать о конечном пользователе отличном от себя любимого разработчика, когда делаешь для более менее общей аудитории, иначе "сам себе папа с мамой"
Ну и общо:
коль скоро объект разрабатывается для группы из N>3 человек то неплохо бы устаканить некий свод правил которые будут соблюдены. Какими бы конкретными или общими они не были.