Здравствуйте, AndrewVK, Вы писали:
AVK>>>Все то же можно сделать и в случае VCS, вопрос в инструменте. ЗХ>>Тогда это будет wiki, реализованная поверх VCS AVK>Неа. VCS намного круче чем wiki. Это вики такая куцая м примитивная VCS.
ничего подобного, wiki это фактически та же VSC, только для документов... а "куцая и примитивная" это недостатки реализации...
Здравствуйте, anonymous, Вы писали:
DG>>ps DG>>вот, что, например, писать про астрологию? DG>>что это лженаука, или что это наука? DG>>а ведь что не напиши, другие обидяться.
A>с этим примером все просто, здесь используется точка зрения официальной науки...
Зачем же? Сама суть NPOV — не выбирать официальную точку зрения. Изложение спорных вопросов выглядит так: "такие-то говорят то-то, приводят следующие аргументы; а такие-то утверждают то-то, и аргументы такие; в официальной науке принято считать что; исторические сложилось; в соотоветствии с такими-то отчетами, 80% жителей уверены что"
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Цель сайта — собрать большую библиотеку полезных code snippets (кусочков кода), могущих легко быть re-used.
Так много всего запланировано...
Я двумя руками ЗА, только какие сроки создания сабжа Вы предполагаете?
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Цель сайта — собрать большую библиотеку полезных code snippets (кусочков кода), могущих легко быть re-used.
Так много всего запланировано...
Я двумя руками ЗА, только какие сроки создания сабжа Вы предполагаете?
Один единственный вопрос — а кто решится это в серьезных программах использовать ? Код, написанный неизвестно кем, доверять ему или нет — неизвестно, насколько он верен — в общем, тоже. Одни писали, другие правили, третьи тестировали... Я бы не решился.
А тесты дело не спасут. Кстати, именно такой подход на олимпиадах АСМ применяется. Прошла программа все тесты — принята. Без изучения кода. Но кто может быть уверен, что она правильна — на этом основании ?
Олимпиады — это игра все же, а для серьезной работы...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Один единственный вопрос — а кто решится это в серьезных программах использовать ? Код, написанный неизвестно кем, доверять ему или нет — неизвестно, насколько он верен — в общем, тоже. Одни писали, другие правили, третьи тестировали... Я бы не решился.
Хм... А никто же не заставляет использовать AS IS... Для меня бы подобный ресурс был бы полезен тем, что я бы смог посмотреть на то как это делают другие люди, чтобы по аналогии написать свое. Ведь нельзя же объять необъятное!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re: Codepedia. Взгляд вглубь. (читать придется много :) )
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Задела меня за живое фраза...
Спасибо, интересное изложение К сожалению, на рсдн пост был воспринят не совсем верно — вместо обсуждения идеи — критика несущественных частей предполагаемой реализации. Попробуем исправить ситуацию
Итак, обсуждаемая идея
Создание открытого универсального хранилища независимых кусочков кода (сниппетов), используя которые, можно легко собирать приложение как конструктор-лего
Вместо предисловия.
Материал для ознакомления.
Спросите у вики. Для тех, кто имеет вопросы о вики, ее работе и принципах, модерации и административном устройстве. В случае острой нехватки времени, достаточно внимательно просмотреть разделы – "Почему Вики не будет действовать", "Зона особого контроля". Это поможет сильно сэкономить время, силы (не только собственные ) и рсдн-овский трафик в дальнейшем
Кодопедия, еще один взгляд
Вооружившись базовым пониманием проблемы, попытаемся разобраться Что же такое независимый кусочек кода?
Давай прикинем, как будут выглядеть сниппеты (обособленный кусочек) на практике.
Примеры
Начнем с самой простой штуки, знакомой с пятого класса
Класс отрезка на плоскости (segment2).
Реализовывать его целиком, смысла нет, поэтому опишем реализацию одного из обязательных алгоритмов — определение точки пересечения двух отрезков (метод intersect).
Возможное решение:
Проводим прямые через вершины отрезков, находим точку их пересечения (*) и проверяем, принадлежит ли она обеим отрезкам.
Стоп. Прямые проводить нельзя — это уже другой класс, а мы договорились избегать зависимостей. Workaround — вставляем код определения пересечения прямых прямо в тело метода intersect и натыкаемся на большую засаду — дублирование кода — один и тот же кусок кода придется использовать для каждой новой сущности — прямой, луча, ломанной, треугольника... Аналогичная ситуация для других алгоритмов.
Звезда синтаксического оверхеда померкла и превратилась в тусклую точку.
Еще один момент — мы не сможем написать код пересечения отрезка и прямой, ведь они локализованы и ничего не знают друг о друге.
Прошу заметить — помимо очевидного дублирования, раздутие кода вступает в конфликт с изначальным положением "окинуть весь код сниппета одним взглядом".
И на самом-то деле, выбор у нас небольшой — создавать связи между классами и отказывать от идеи независимости или дублировать код.
Поток (тот, который Thread)
Достаточно быстро бросается в глаза, что он может существовать только в контексте процесса, напрямую связан с критическими секциями и кучей других средств синхронизации. Термин поток просто не применим на практике в отрыве от других понятий предметной области.
Регэксп
Штука жутко распространенная, полезная и компактная — любое вменяемое регулярное выражение можно уместить в одну строчку.
Новая неприятность — реализацию регэкспов, вряд ли можно окинуть одним взглядом, да вдобавок, строятся они на конечных автоматах (КА), классе который, безусловно, также присутствует в нашей кодопедии — получаем неустранимую зависимость между сниппетами.
Еще одно важное замечание. В википедии можно записать — "базой для регэкспов являются КА", дать "висящую" ссылку, и кто-то добрый, позднее, составит статью КА. С кодом такой фокус не пройдет – для компилируемости и корректной работы регулярных выражений (и их тестов) необходим законченный конечный автомат.
Кроме того, как и каждую блестящую идею, кодопедию может запороть куча "бытовых" "мелочей" — подход к обработке ошибок, использование юникода и т.д. (рабочий код, решающий одинаковые задачи может сильно отличаться в зависимости от условий применения)
Почему же часто не получается выделить сниппеты?
Потому что код, описывающий некоторую предметную область, оперирует не одним единственным термином, а группой понятий полностью ее покрывающих.
Пардон, а как же википедия?
Открываем любую ссылку на http://wikipedia.org, внимательно и пристально на нее смотрим минуту.
Оказывается, в вики нет ни одного независимого термина. На любой страничке можно увидеть кучу гиперссылок, направленных, как внутрь энциклопедии, так и вне ее (это интересный момент) — получается кодопедия в изначальной своей задумке, являла вовсе не аналог википедии, а ее полный антипод.
Более того, после некоторого размышления, приходим к очевидному выводу — действительно независимых кусочков кода, не так уж и много.
Неужели все так плохо?
Заметим одно — вовсе не нужно бежать от предметной области каждого сниппета, лучше воспринимать ее такой, какой она есть , аки любимая женщина со всеми достоинствами и недостатками.
Отложим пока этот вопрос немного на потом и посмотрим, Что есть сейчас и как можно использовать чужие наработки?
А есть, на самом деле, многое
Как выглядит использование "совсем чужого кода" (**) на практике? Ищется он (код) достаточно просто, хоть и тоскливо — запрос, определение релевантности результата, коррекция запроса… действо, как кажется, знакомое с младенчества.
Далее анализ кода. Не только муторный, но и весьма утомительный процесс. Отбрасываются грязный исходный код, анализируется архитектура, решения конкретных проблем, стиль написания, оценивается возможность адаптации к своему проекту... Честно скажу, меня надолго не хватает — через три-четыре часа плотной загрузки, рабочий день заканчивается. Дивиденды? Они есть и их много. Помимо того, что мы можем уточнить собственную задачу и лучше въехать в тему, в ход можно отправить если не все, то многое — части кода (иногда и правда, целые классы), названия методов, функций и переменных (вопрос о компактном, красивом и точном имени чего угодно не оставит безучастным ни одну душу ), архитектурные решения, способы обхода возникавших проблем, тонкости реализации, наконец полезными могут оказаться просто ссылки в коде на онлайн-документы. В результате, получаем приличную экономию время и силы. Вывод: банален до безобразия и знаком с первого курса — применять чужой код можно и нужно.
Что мешает искать и использовать чужой код?
Беда кроется как минимум в трех объективных причинах — отсутствии приличной каталогизации, качественной документации (здесь появляется некоторая, тонкая связь с Doxygen, JavaDoc со товарищи...
, но об этом попозже ) и неопределенная надежность.
Объективная сложность поиска.
Тратить несколько часов на поиск и просеивание чужого кода — не самое приятное времяпровождение (да и успех не гарантирован).
Однако, допустим, во время наших поисков было найдено решение, вроде бы подходящее для нашей задачи, но станем ли мы использовать его? Большой вопрос.
Чем определяется степень доверия чужому коду.
Отзывы и использование в других проектах.
Степень покрытия, и качество юнит-тестов
Документация
Время без крупных правок. Косвенно говорит о стабильности кода. (естессно, тут идет речь о постоянно используемом коллегами коде, а не трех строчках положенных на http://sf.net пять лет назад анонимом)
Если все условия выполняются, то почему бы и нет — такому коду вполне можно доверять. Но таких сниппетов, увы, встретится весьма немного.
Что больше всего отпугивает программиста в чужом решении?
Неизвестны условия использования автором и применимость к текущим условиям.
Попросту говоря, когда мы открываем чужой исходник, остается только догадываться какими мотивами руководствовался автор при написании своего детища, соответственно мы не можем сказать, а подойдет ли это решение нам.
Ограничения по используемым технологиям и особенностям языка, стиль разработки и оформления кода, exception safety и миллион других вопросов — на всех них можно получить ответы только одним способом — тщательно проанализировав весь код. Как правило, это более чем утомительно, более того, исследовать кучу сниппеттов, а потом прийти к выводу, что ни один тебе не годится — весьма печально, именно отсюда растут корни велосипедостроения.
Чего хотелось бы видеть в документации?
(помимо one-minute description, five minute introduction, ten minute tutorial и проч клиентского стаффа — сейчас разговор только про кодопедию)
Для решения какой проблемы был создан код. Четкое перечисление используемых технологий, сторонних библиотек и возможностей языка. Обязательно, ссылки на предметную область и дискуссии по поводу архитектуры (здесь важным становится критика, и четко очерченная область применения); альтернативные реализации сниппета, их качественное сравнение.
Т.е. прежде всего, документация должна отвечать на вопрос "почему?"
Наличие такой подробной документации требуется для нескольких целей — понизить требуемый уровень добровольца для вхождения в проект, упростить внесение изменений и наконец, четко показать клиенту кодопедии, а подойдет ли ему этот сниппет, а если даже нет — то в какую сторону потребуется двигаться, чтобы адаптировать его под свои нужды.
Пример такой документации можно посмотреть здесь
А простой пользователь может и вовсе никогда не заглядывать в эти дискуссии — они ему попросту не нужны.
Индустрия давно уловила это веяние — поэтому и появились форумы подобные rsdn или тематические ньюз-группы, более того сейчас эта идея активно развивается — целью некоторых новых проектов является не только хранение кода, но и его обсуждение "где-то рядом" — например Trac, отчасти Каким должен быть сайт сообщества будущего?
Итак, что же требуется для решения проблем?
Категоризация. Документирование.
Кто и как будет заниматься их решением? Кто угодно — код и документация могут свободно редактироваться. Пример вики показывает, что этот прием работает.
Чем в итоге получился сниппет?
А вот не знаю
Ясно одно — принцип "окинуть весь код сниппета одним взглядом" можно будет применить не всегда.
Нужны ли юнит-тесты?
Имхо, это краеугольный камень, на котором будет держаться весь проект, решающий помимо прочего три задачи:
поддержание кода в работоспособном состоянии
антивандализм
повышение степени доверия
Но
Честно говоря, с большим скепсисом отношусь к юнит тестам в качестве способа документирования – в самом деле, посмотрим на MultiByteToWideChar — вполне себе сниппет (хоть и на костылях). Возможно, не белый, компактный и пушистый , это уж звиняйте, зато рабочий и используемый ( Пусть кричат "Уродина!" А она нам нравится! Хоть и не красавица!
) Рискну предположить, что юнит-тест для такой функции будет иметь весьмааа нехилый размер.
Так вот, если построить в длинную очередь тех, кто будет шарахаться от изучения сниппетов по таким чудным тестам – Зверёк окажется в первой тройке и будет ругаться за то, кто должен идти первым
К сожалению, юнит-тесты не идеальное средство для тестирования кода, а иногда их и вовсе невозможно использовать. Простейший пример — сниппет проигрывающий звук с постепенным понижением громкости.
Резюмируя — тема тестирования открыта для новых идей.
Очень не хочется об этом говорить, но не сказать нельзя.
Пять тонн хрусталя отличной идеи падает с высоты километра, — необходимо определить, по какой лицензии будет распространяться код (больше писать ничего не буду)
Вывод.
Его пока нет Обсуждаем
Пожалуй, все. Хотя, нет.
То, что обсуждалось в дискуссии и не вошло в этот пост.
Реализация. Wikipedia или VСS? Вопрос слишком ранний — какая разница, как — текст можно отредактировать в блокноте или вики (естессно, онлайн эдитор предпочтительнее и в идеале должен быть именно он), но пока разговор об идее. Прочие вопросы по реализации — двадцать пятые и тридцать седьмые — пинаем их ногами в конец очереди.
Как быть с наличием нескольких языков? Проще, чем кажется. Как и в википедии, каждому языку — своя площадка. Пусть никто не уйдет обиженным (c).
Что необходимо для запуска проекта?
Удачная базисная технология — как вики для редактирования текста. Большое стартовое кол-во добровольцев и несколько стабильных лидеров. Возможно, что-то еще — пока об этом рано говорить.
Была еще пара мыслей, но они вылетели из головы раньше, чем успел их записать
Вот. Теперь точно все.
Спасибо.
(*) для простоты, случаи совпадения и параллельности прямых, не рассматриваем.
(**) для педантов. Совсем чужой код – тот, который мы получили не от коллег по работе, организаций-партнеров или извлекли из известных библиотек, а от совершенно неизвестного лица. Степень доверия и качества кода — неопределенная.
Здравствуйте, FreshMeat, Вы писали:
FM> Класс отрезка на плоскости (segment2). FM>Реализовывать его целиком, смысла нет, поэтому опишем реализацию одного из обязательных алгоритмов — определение точки пересечения двух отрезков (метод intersect). FM>Возможное решение: FM>Проводим прямые через вершины отрезков, находим точку их пересечения (*) и проверяем, принадлежит ли она обеим отрезкам. FM>Стоп. Прямые проводить нельзя — это уже другой класс, а мы договорились избегать зависимостей. Workaround — вставляем код определения пересечения прямых прямо в тело метода intersect и натыкаемся на большую засаду — дублирование кода — один и тот же кусок кода придется использовать для каждой новой сущности — прямой, луча, ломанной, треугольника... Аналогичная ситуация для других алгоритмов. FM>Звезда синтаксического оверхеда померкла и превратилась в тусклую точку. FM>Еще один момент — мы не сможем написать код пересечения отрезка и прямой, ведь они локализованы и ничего не знают друг о друге. FM>Прошу заметить — помимо очевидного дублирования, раздутие кода вступает в конфликт с изначальным положением "окинуть весь код сниппета одним взглядом". FM>И на самом-то деле, выбор у нас небольшой — создавать связи между классами и отказывать от идеи независимости или дублировать код.
все-таки мне кажется, что сниппет не должен быть больше функции (и уж точно не классом, по крайней мере пока)... и тогда вопрос предельно упрощается: есть четыре точки, через которые проходят две прямые, пресекаются ли они?... итог: функция, на входе которой 8 переменных с координатами, на выходе — булево значение... и теперь любой программист может взять её и использовать в одном из собственных классов описывающих геометрию, т. о. дублирования кода не будет...
Re[3]: Codepedia. Взгляд вглубь. (читать придется много :) )
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, FreshMeat, Вы писали:
FM>> Класс отрезка на плоскости (segment2). FM>>Реализовывать его целиком, смысла нет, поэтому опишем реализацию одного из обязательных алгоритмов — определение точки пересечения двух отрезков (метод intersect). FM>>Возможное решение: FM>>Проводим прямые через вершины отрезков, находим точку их пересечения (*) и проверяем, принадлежит ли она обеим отрезкам. FM>>Стоп. Прямые проводить нельзя — это уже другой класс, а мы договорились избегать зависимостей. Workaround — вставляем код определения пересечения прямых прямо в тело метода intersect и натыкаемся на большую засаду — дублирование кода — один и тот же кусок кода придется использовать для каждой новой сущности — прямой, луча, ломанной, треугольника... Аналогичная ситуация для других алгоритмов. FM>>Звезда синтаксического оверхеда померкла и превратилась в тусклую точку. FM>>Еще один момент — мы не сможем написать код пересечения отрезка и прямой, ведь они локализованы и ничего не знают друг о друге. FM>>Прошу заметить — помимо очевидного дублирования, раздутие кода вступает в конфликт с изначальным положением "окинуть весь код сниппета одним взглядом". FM>>И на самом-то деле, выбор у нас небольшой — создавать связи между классами и отказывать от идеи независимости или дублировать код.
A>все-таки мне кажется, что сниппет не должен быть больше функции (и уж точно не классом, по крайней мере пока)... и тогда вопрос предельно упрощается: есть четыре точки, через которые проходят две прямые, пресекаются ли они?... итог: функция, на входе которой 8 переменных с координатами, на выходе — булево значение... и теперь любой программист может взять её и использовать в одном из собственных классов описывающих геометрию, т. о. дублирования кода не будет...
Абсолютно согласен! Никаких глобальных вещей сниппет (ну и слово...) использовать не должен. Это должен быть черный ящик с набором входов, выходов и желательно без побочных эффектов, желательно с проверкой внешних зависимостей: язык, необходимые внешние библиотеки. Поэтому помимо тегов необходим язык описания сниппетов. Сюда же относятся test модули, а там глядишь и софт появится для автоматизации проверки.
Re[3]: Codepedia. Взгляд вглубь. (читать придется много :) )
Здравствуйте, anonymous, Вы писали:
A>все-таки мне кажется, что сниппет не должен быть больше функции (и уж точно не классом, по крайней мере пока)... и тогда вопрос предельно упрощается: есть четыре точки, через которые проходят две прямые, пресекаются ли они?... итог: функция, на входе которой 8 переменных с координатами, на выходе — булево значение... и теперь любой программист может взять её и использовать в одном из собственных классов описывающих геометрию, т. о. дублирования кода не будет...
Таким образом отказываемся от ООП.
Компактно-крохотных сниппетов может оказаться совсем немного.
Плюс, если копнуть чуть глубже, появляются новые неприятности:
если мы говорим о C++
template < typename T >
bool is_intersect_lines2( T p00x, T p00y, T p01x, T p01y,
T p10x, T p10y, T p11x, T p11y );
1. при каждом вызове ф-ии, необходимо проверять вырожденные случаи —
если мы будем использовать классы, можно делать такую проверку один раз в конструкторе.
Конечно, эту проблему можно переложить на пользователя, потребовать обязательно проверять передаваемые параметры, но тогда код становится более опасным (для меня это было бы уже достаточной причиной отказаться от использования такого сниппета)
p00x == p01x Эту операцию должен предоставлять пользователь — получаем еще один параметр у is_intersect_lines2, указатель на функцию сравнения.
2. Немножно субъективизма.
Посмотрим на другую ф-ю — определение точки пересечения прямых в 3d. Просто прикинем ее сигнатуру. Координаты входящих точек — шесть параметров, ф-я сравнения — один, результат — еще три. Итого — 10
template < typename T >
bool intersect_lines3( T p00x, T p00y, T p00z, T p01x, T p01y, T p01z,
T p10x, T p10y, T p10z, T p11x, T p11y, T p11z,
is_equal_t equal,
T* resx, T* resy, T* resz );
К чему это говорю — такую страшилку использовать в своем проекте захочется только от большоой тоски, чесслово
Хорошо там, где мы есть! :)
Re[4]: Codepedia. Взгляд вглубь. (читать придется много :) )
Здравствуйте, FreshMeat, Вы писали:
FM>Таким образом отказываемся от ООП.
да, выходит так... либо придется писать в аннотации что-то вроде:
template < class T >
bool is_intersect_lines2( T l0, T l1 );
Класс прямой T толжен иметь атрибуты с названиями p0x, p0y, p1x, p1y, в которых хранятся координаты точек, через которые проходит данная прямая.
FM>Компактно-крохотных сниппетов может оказаться совсем немного.
в этом я не уверен, все же алгоритмов существует достаточно много, плюс различные реализации этих алгоритмов...
FM>Плюс, если копнуть чуть глубже, появляются новые неприятности: FM>если мы говорим о C++ FM>
FM>template < typename T >
FM>bool is_intersect_lines2( T p00x, T p00y, T p01x, T p01y,
FM> T p10x, T p10y, T p11x, T p11y );
FM>
FM>1. при каждом вызове ф-ии, необходимо проверять вырожденные случаи — FM>
FM>если мы будем использовать классы, можно делать такую проверку один раз в конструкторе. FM>Конечно, эту проблему можно переложить на пользователя, потребовать обязательно проверять передаваемые параметры, но тогда код становится более опасным (для меня это было бы уже достаточной причиной отказаться от использования такого сниппета)
согласен... хотя переложить эту проблему на пользователя не такая уж и плохая идея, просто нужно честно предупредить его в аннотации о всех ограничениях...
к примеру, хочет пользователь метод CLine.IsIntersectWith(CLine&), берёт он функцию is_intersect_lines2() и вставляет её вызов в тело метода... проверка подобная указанной уже не нужна, поскольку реализована в конструкторе CLine...
есть ещё идея автоматически генерировать такие методы, по некоему описанию класса, заданному пользователем, на основе вот таких сниппетов функций... но как, пока не ясно...
FM>p00x == p01x Эту операцию должен предоставлять пользователь — получаем еще один параметр у is_intersect_lines2, указатель на функцию сравнения.
при использовании классов будет то же самое... кроме того, поскольку ООП не будет, то будут использоваться только базовые типы, а для них эта операция определена...
FM>2. Немножно субъективизма. FM>Посмотрим на другую ф-ю — определение точки пересечения прямых в 3d. Просто прикинем ее сигнатуру. Координаты входящих точек — шесть параметров, ф-я сравнения — один, результат — еще три. Итого — 10 FM>
FM>template < typename T >
FM>bool intersect_lines3( T p00x, T p00y, T p00z, T p01x, T p01y, T p01z,
FM> T p10x, T p10y, T p10z, T p11x, T p11y, T p11z,
FM> is_equal_t equal,
FM> T* resx, T* resy, T* resz );
FM>
FM>К чему это говорю — такую страшилку использовать в своем проекте захочется только от большоой тоски, чесслово
честно говоря, не вижу смысла в такой функции, её можно разделить на три вызова intersect_lines2()...
Re[4]: Codepedia. Взгляд вглубь. (читать придется много :) )
Здравствуйте, FreshMeat, Вы писали:
FM>Здравствуйте, anonymous, Вы писали:
A>>все-таки мне кажется, что сниппет не должен быть больше функции (и уж точно не классом, по крайней мере пока)... и тогда вопрос предельно упрощается: есть четыре точки, через которые проходят две прямые, пресекаются ли они?... итог: функция, на входе которой 8 переменных с координатами, на выходе — булево значение... и теперь любой программист может взять её и использовать в одном из собственных классов описывающих геометрию, т. о. дублирования кода не будет... FM>Таким образом отказываемся от ООП. FM>Компактно-крохотных сниппетов может оказаться совсем немного.
FM>Плюс, если копнуть чуть глубже, появляются новые неприятности: FM>если мы говорим о C++ FM>
FM>template < typename T >
FM>bool is_intersect_lines2( T p00x, T p00y, T p01x, T p01y,
FM> T p10x, T p10y, T p11x, T p11y );
FM>
FM>1. при каждом вызове ф-ии, необходимо проверять вырожденные случаи — FM>
FM>если мы будем использовать классы, можно делать такую проверку один раз в конструкторе. FM>Конечно, эту проблему можно переложить на пользователя, потребовать обязательно проверять передаваемые параметры, но тогда код становится более опасным (для меня это было бы уже достаточной причиной отказаться от использования такого сниппета)
Входные параметры надо проверять всегда на попадание в область допустимых значений.
Если мы используем класс, то это уже IMHO не сниппет
Re[5]: Codepedia. Взгляд вглубь. (читать придется много :) )
FM>>Компактно-крохотных сниппетов может оказаться совсем немного. A>в этом я не уверен, все же алгоритмов существует достаточно много, плюс различные реализации этих алгоритмов...
Да, действительно, только получается вот какая ситуация: у нас будут реализованы алгоритмы — пересечение линий, совпадение отрезков, отсечение треугольника, попадание точки внутрь многоугольника, проверка многоугольника на самопересечения и выпуклость и т.д. — будет много действий, но не будет понятий, над которыми эти действия производятся. Странно
FM>>Конечно, эту проблему можно переложить на пользователя, потребовать обязательно проверять передаваемые параметры, но тогда код становится более опасным (для меня это было бы уже достаточной причиной отказаться от использования такого сниппета)
A>согласен... хотя переложить эту проблему на пользователя не такая уж и плохая идея, просто нужно честно предупредить его в аннотации о всех ограничениях... A>к примеру, хочет пользователь метод CLine.IsIntersectWith(CLine&), берёт он функцию is_intersect_lines2() и вставляет её вызов в тело метода... проверка подобная указанной уже не нужна, поскольку реализована в конструкторе CLine...
Да, можно, но перед тем, как использовать такой код, я трижды подумаю
A>есть ещё идея автоматически генерировать такие методы, по некоему описанию класса, заданному пользователем, на основе вот таких сниппетов функций... но как, пока не ясно...
Интересная идея. Надо осмыслить.
FM>>p00x == p01x Эту операцию должен предоставлять пользователь — получаем еще один параметр у is_intersect_lines2, указатель на функцию сравнения. A>при использовании классов будет то же самое...
Да, при любом подходе будем иметь зависимость от этой операции. A>кроме того, поскольку ООП не будет, то будут использоваться только базовые типы, а для них эта операция определена... Не так, как нужно — нам придется расширять ее, чтобы учитывалась погрешность (один из возможных вариантов).
FM>>2. Немножно субъективизма. FM>>Посмотрим на другую ф-ю — определение точки пересечения прямых в 3d. Просто прикинем ее сигнатуру. FM>>... FM>>К чему это говорю — такую страшилку использовать в своем проекте захочется только от большоой тоски, чесслово A>честно говоря, не вижу смысла в такой функции, её можно разделить на три вызова intersect_lines2()...
Может не совсем точно выразился — ф-я должна найти точку пересечение двух прямых в трехмерном пространстве.
Хорошо там, где мы есть! :)
Re[5]: Codepedia. Взгляд вглубь. (читать придется много :) )
Здравствуйте, henson, Вы писали:
H>Входные параметры надо проверять всегда на попадание в область допустимых значений.
Верно. Но тогда имеем прогиб по производительности — эта операция будет выполняться при каждом поиске пересечений, вместо одного — во время создания класса. H>Если мы используем класс, то это уже IMHO не сниппет
Может быть. По крайней мере не такой, который хотелось бы — компактный и независимый.
Хорошо там, где мы есть! :)
Re[6]: Codepedia. Взгляд вглубь. (читать придется много :) )
да, пожалуй я также начинаю склонятся к фреймворку, но... (см. ниже)
A>>есть ещё идея автоматически генерировать такие методы, по некоему описанию класса, заданному пользователем, на основе вот таких сниппетов функций... но как, пока не ясно... FM>Интересная идея. Надо осмыслить.
вариант: пльзователь имеет класс SomeLine — прямую и хочет определить пресекается ли эта прямая с другой прямой, для чего создаёт метод IsIntersectWith(Line&) и описывает его как:
bool intersect_line2(int p00x, int p00y, int p01x, int p01y, int p10x, int p10y, int p11x, int p11y) {
...
}
в результате после обработки код сниппета intersect_line2 вставляется в Line::IsIntersectWith с заменой переменных p00x на this.p0x, p00y на this.p0y и т. п... (ну и конечно типы еще указывать надо...) в итоге получаем рабочий метод без страшных параметров...
зачем это надо: затем, чтобы пользователь не зависел от других классов Codepedia и мог создавать свои... в данном случае пользователь создал сразу класс Line с координатами точек, а ведь мог сначала создать красс точек Point, который затем использовать в классе Line, либо пойти каким то третьим путём... и в каждом из этих случаев обращение к параметрам функции различается...
FM>Может не совсем точно выразился — ф-я должна найти точку пересечение двух прямых в трехмерном пространстве.
это просто я невнимателен... а зачем 3 результата?...
Здравствуйте, Anton Batenev, Вы писали:
N>>- человеком двигали вполне благие намерения. И движок там от Википедии (Медиавики). А получилось черти что. А все почему? Потому что (i) не надо распыляться и пытаться охватить все на свете и (ii) очень важна грамотная классификация/категоризация.
AB>Хм... а что именно там "черти что"? На первый беглый взгляд достаточно интересный проектик и почти то, что Зверек описывал.
Черти что там то, что как раз (i) и (ii). А раз там так, то непонятно что же должно привлекать потенциальных наполнителей контента. Любой может поднять MediaWiki и сделать свое пустое (но очень широкое по взглядам) содержание и свою пустую (но неудачную) категоризацию.
Здравствуйте, nzeemin, Вы писали:
N>http://ru.livecode.org/index.php/Заглавная_Страница N>- человеком двигали вполне благие намерения. И движок там от Википедии (Медиавики). А получилось черти что. А все почему? Потому что (i) не надо распыляться и пытаться охватить все на свете и (ii) очень важна грамотная классификация/категоризация.
еще проект: http://alglib.sources.ru/
тут алгоритмы описаны внутренним языком программирования, и пользователь может выбрать нужеый ему язык, после чего транслятор переводит алгоритм на выбранный язык...
) и рсдн-овский трафик в дальнейшем 
, это уж звиняйте, зато рабочий и используемый ( Пусть кричат "Уродина!" А она нам нравится! Хоть и не красавица!
