Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Задела меня за живое фраза...
Спасибо, интересное изложение К сожалению, на рсдн пост был воспринят не совсем верно — вместо обсуждения идеи — критика несущественных частей предполагаемой реализации. Попробуем исправить ситуацию
Итак, обсуждаемая идея
Создание открытого универсального хранилища независимых кусочков кода (сниппетов), используя которые, можно легко собирать приложение как конструктор-лего
Вместо предисловия.
Материал для ознакомления.
Спросите у вики. Для тех, кто имеет вопросы о вики, ее работе и принципах, модерации и административном устройстве. В случае острой нехватки времени, достаточно внимательно просмотреть разделы – "Почему Вики не будет действовать", "Зона особого контроля". Это поможет сильно сэкономить время, силы (не только собственные ) и рсдн-овский трафик в дальнейшем
Кодопедия, еще один взгляд
Вооружившись базовым пониманием проблемы, попытаемся разобраться Что же такое независимый кусочек кода?
Давай прикинем, как будут выглядеть сниппеты (обособленный кусочек) на практике.
Примеры
Начнем с самой простой штуки, знакомой с пятого класса
Класс отрезка на плоскости (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).
Что необходимо для запуска проекта?
Удачная базисная технология — как вики для редактирования текста. Большое стартовое кол-во добровольцев и несколько стабильных лидеров. Возможно, что-то еще — пока об этом рано говорить.
Была еще пара мыслей, но они вылетели из головы раньше, чем успел их записать
Вот. Теперь точно все.
Спасибо.
(*) для простоты, случаи совпадения и параллельности прямых, не рассматриваем.
(**) для педантов. Совсем чужой код – тот, который мы получили не от коллег по работе, организаций-партнеров или извлекли из известных библиотек, а от совершенно неизвестного лица. Степень доверия и качества кода — неопределенная.
Пока ходил на базар за картошкой — сформулировал, как это могло бы выглядеть. Решил поделиться — авось кому польза будет Дисклямер: в нижеследующем тексте я не учитываю возможных технических ограничений; исхожу из того, что сервер ориентирован на 1 язык (из мейнстримовых).
Цель сайта — собрать большую библиотеку полезных code snippets (кусочков кода), могущих легко быть re-used.
Единица хранения
Один snippet — это некий набор единиц языка (классов, функций), не зависящий от сторонних библиотек (кроме стандартной библиотеки данного языка), служащий однозначно формулируемой цели, и могущий быть использованным "как есть", без переделки.
Поскольку однозначного имени (по которому любой программист его найдет) snippet'у дать нельзя, ему дается краткое описание и набор тегов (соответственно, поиск сниппета на сайте — отбор по тегам).
Редактирование snippets
Редактировать сниппет может кто угодно.
Для редактирования сниппета сайт должен предоставлять полноценный редактор кода (подсветка, автоотступ, сворачивание веток, autocomplete стандартной библиотеки).
Необходимо ввести сниппет и юнит-тест на него (код выполняющий проверку корректности сниппета и одновременно — демонстрацию его возможностей).
После этого сервер выполняет проверку.
Проверяется: синтаксис и компилируемость кода, стиль (на сервере существуют некоторые правила, типа длины имен переменных и прочая); выполняется юнит-тест. Результатом выполнения юнит-теста является список тестов, которые код прошел/не прошел, а так же (в идеале) покрытие кода тестами (какие классы/функции в выполнении юнит-теста задействованы не были).
Код, не прошедший проверку на компилируемость, запостить нельзя. Код, не прошедший критические тесты, запостить нельзя. Код, не прошедший некритические тесты, запостить можно, в каталоге он будет показан как "сниппет такой-то — проходит 80% тестов".
Поиск и выбор snippets
Поиск идет по тегам и просто через поисковую систему. В списке отображается сниппет, его краткое описание, покрытие юнит-тестами (рейтинг?). При просмотре сниппета можно посмотреть его код, юнит-тест, результат выполнения юнит-теста, автоматически сгененрированное summary (только definitions). При этом сайт должен поддерживать простой рефакторинг — единожды задав в своем профайле свои соглашения по кодированию (отступы, переносы, case переменных и прочая), дальше все сниппеты вижу отформатированными по этим соглашениям. Просматриваемый сниппет можно загрузить (в смысле, соответствующий исходник без html'я), отредактировать, отредактировать только юнит-тест (к примеру, добавить еще один тест, демонстрирующий некорректность кода, или нехватающие в нем фичи).
Административное устройство
По всей видимости, кроме модераторов (чья функция — как всегда — пресекать хулиганство и вандализм) нужны maintainers (добровольцы-энтузиасты), которые станут более-менее регулярно просматривать новые и измененные сниппеты, выбрасывать никому-не-нужные, рефакторить плохо-написанные и т.п.
На закуску — проблемы реализации
Крутейшая среда с рефакторингом и веб-интерфейсом, серверная, выдерживающая дикие нагрузки — это не шубу в трусы заправить. Других проблем не видать Возможно, нагрузку можно каким-то образом перенести на клиента (скачивается программа, в которую уже встроен редактор; каким-то образом полагаться на установленный у клиента компилятор, и т.п.). JetBrains, ау?!
ну и под конец...
когда сниппетов наберется под несколько миллионов — это через несколько лет полноценной работы сайта, и стоимость места на жестком диске и оперативной паямяти клентских компбютеров станут равны фактически 0 (!), а процессорные мощности станут фактически безграничными....
то встанет вопрос о созлании клиентского приложения, которое после ввода описания задачи на уже упоминавшемся языке тэгов для описаний снипеттов, будет загружать эти сниппеты и компоновать и компилить их в произвольном порядке, за несколько минут/часов создавая гигантские многофункцональные приложения...
и наступит рай на земле...
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Хотелось бы репозиторий кода, основанный на принципах Wikipedia. ЗХ>А конкретно, на важнейшем ее принципе: любой кусочек информации может править любой человек. ЗХ>Мне кажется, что это дало бы (по аналогии с той же Wikipedia) итеративно улучшаемые (в пределе — идеальные) самостоятельные тематические кусочки кода.
Посмотри вот это: http://ru.livecode.org/index.php/Заглавная_Страница
— человеком двигали вполне благие намерения. И движок там от Википедии (Медиавики). А получилось черти что. А все почему? Потому что (i) не надо распыляться и пытаться охватить все на свете и (ii) очень важна грамотная классификация/категоризация.
Здравствуйте, FreshMeat, Вы писали:
FM> Класс отрезка на плоскости (segment2). FM>Реализовывать его целиком, смысла нет, поэтому опишем реализацию одного из обязательных алгоритмов — определение точки пересечения двух отрезков (метод intersect). FM>Возможное решение: FM>Проводим прямые через вершины отрезков, находим точку их пересечения (*) и проверяем, принадлежит ли она обеим отрезкам. FM>Стоп. Прямые проводить нельзя — это уже другой класс, а мы договорились избегать зависимостей. Workaround — вставляем код определения пересечения прямых прямо в тело метода intersect и натыкаемся на большую засаду — дублирование кода — один и тот же кусок кода придется использовать для каждой новой сущности — прямой, луча, ломанной, треугольника... Аналогичная ситуация для других алгоритмов. FM>Звезда синтаксического оверхеда померкла и превратилась в тусклую точку. FM>Еще один момент — мы не сможем написать код пересечения отрезка и прямой, ведь они локализованы и ничего не знают друг о друге. FM>Прошу заметить — помимо очевидного дублирования, раздутие кода вступает в конфликт с изначальным положением "окинуть весь код сниппета одним взглядом". FM>И на самом-то деле, выбор у нас небольшой — создавать связи между классами и отказывать от идеи независимости или дублировать код.
все-таки мне кажется, что сниппет не должен быть больше функции (и уж точно не классом, по крайней мере пока)... и тогда вопрос предельно упрощается: есть четыре точки, через которые проходят две прямые, пресекаются ли они?... итог: функция, на входе которой 8 переменных с координатами, на выходе — булево значение... и теперь любой программист может взять её и использовать в одном из собственных классов описывающих геометрию, т. о. дублирования кода не будет...
Здравствуйте, nzeemin, Вы писали:
N>http://ru.livecode.org/index.php/Заглавная_Страница N>- человеком двигали вполне благие намерения. И движок там от Википедии (Медиавики). А получилось черти что. А все почему? Потому что (i) не надо распыляться и пытаться охватить все на свете и (ii) очень важна грамотная классификация/категоризация.
еще проект: http://alglib.sources.ru/
тут алгоритмы описаны внутренним языком программирования, и пользователь может выбрать нужеый ему язык, после чего транслятор переводит алгоритм на выбранный язык...
Здравствуйте, Anton Batenev, Вы писали:
N>>- человеком двигали вполне благие намерения. И движок там от Википедии (Медиавики). А получилось черти что. А все почему? Потому что (i) не надо распыляться и пытаться охватить все на свете и (ii) очень важна грамотная классификация/категоризация.
AB>Хм... а что именно там "черти что"? На первый беглый взгляд достаточно интересный проектик и почти то, что Зверек описывал.
Черти что там то, что как раз (i) и (ii). А раз там так, то непонятно что же должно привлекать потенциальных наполнителей контента. Любой может поднять MediaWiki и сделать свое пустое (но очень широкое по взглядам) содержание и свою пустую (но неудачную) категоризацию.
Сразу хочется сказать:
1. Языков до фигищи, и как запускать и оценивать?
2. Не на все можно настроить Unit тесты. А тем-более описать.
3. Оценивать по результатом тестов? Это не очень хорошо. Нужно оценивать КПД библиотеки. А тут все слишком субъективно. Реакция пользователей, вот должна быть оценка. А это уже есть, форум "Исходники".
4. Мне иногда значительно полезнее идеи, чем работающие исходники. Даже я бы сказал более полезны и нужны. А тут не все полезные идеи можно запихнуть(по п1,2) При этом, я могу субъективно оценить идею по данной оценке(п3).
Единственное что не хватает в форуме исходников, это система поиска и тегов. Это действительно так. И лучше всего, чтобы они были редактируемыми(пользователь мог оценить направленность), и модерируемыми(модераторы оценивали вменяемость направленности).
[offtop]
Нет, ну действительно нечто типа "незримого поля" идей существует — неделю назад мимо меня пробегала такая идея, улыбнулась, сделала книксен и побежала дальше
[/offtop]
...добивая ногами психиатра: "Это кто нервный?! Это я нервный?!!"
Если снипет и компонент — это примерно одно и тоже, то как будут решаться проблемы, которые характерны при использование компонентов:
1. Избыточность
2. Монолитность
3. Различие в терминах
4. Различие в моделях
5. Различие в подходах
SR>[offtop] SR>Нет, ну действительно нечто типа "незримого поля" идей существует — неделю назад мимо меня пробегала такая идея, улыбнулась, сделала книксен и побежала дальше SR>[/offtop]
Здравствуйте, DarkGray, Вы писали:
ЗХ>>Для всех остальных скопом: вопрос — почему Википедия настолько хороша?
DG>Хороша — по сравнению с чем?
По сравнению (а) с офлайновыми энциклопедиями, (б) с другими источниками энциклопедической информации в интернете.
DG>ps DG>Один из ответов — потому, что это первая реальная реализация hyper-текстовой энциклопедии,
Правильный ответ — потому что она редактируема всеми в любой момент времени. Т.е. реализует итеративный процесс создания информации "всем миром".
DG>но при этом я бы не сказал, что wikipedia-ей реально удобно пользоваться.
Зверёк Харьковский,
> DG>Хороша — по сравнению с чем? > > По сравнению (а) с офлайновыми энциклопедиями, (б) с другими источниками энциклопедической информации в интернете.
Она далеко не так уж универсально хороша в этом сравнении. Все зависит от критериев. Например, у меня ко многим другим источникам справочной информации намного выше доверие в смысле достоверности информации.
> Правильный ответ — потому что она редактируема всеми в любой момент времени. Т.е. реализует итеративный процесс создания информации "всем миром".
Именно поэтому.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Зверёк Харьковский,
>> DG>Хороша — по сравнению с чем? >> >> По сравнению (а) с офлайновыми энциклопедиями, (б) с другими источниками энциклопедической информации в интернете.
ПК>Она далеко не так уж универсально хороша в этом сравнении. Все зависит от критериев. Например, у меня ко многим другим источникам справочной информации намного выше доверие в смысле достоверности информации.
Подчеркиваю — энциклопедической. Как правило, Википедия представляет собой великолепный starting point для ознакомления с незнакомым понятием. При этом подробнее, чем любая офлайновая энциклопедия, и достовернее, чем набрать в гугле "искомое понятие" и перейти по паре перво-попавшихся ссылок. Я имел в виду уименно это.
Здравствуйте, DarkGray, Вы писали:
DG>>>но при этом я бы не сказал, что wikipedia-ей реально удобно пользоваться.
ЗХ>>???
DG>Структуризации — нет,
Ну, вообще-то категории там есть.
DG>поддержки нескольких точек зрения — нет,
Мммм... Мне кажется, для энциклопедии правильный подход — именно используемый в Википедии NPOV (Neutral Point Of View)
DG>поддержки выборок, фильтров и т.д. — нет, DG>фрактализации — нет. DG>и т.д.
Хотелось бы заметить, что это все-таки энциклопедия, а не "путеводитель по миру". Цель энциклопедии — отвечать на вопрос "что такое <понятие>", а не организовывать весь мир в логическую структуру.
Господа, я возможно не вполне точно выразил намерения и цели.
Хотелось бы репозиторий кода, основанный на принципах Wikipedia.
А конкретно, на важнейшем ее принципе: любой кусочек информации может править любой человек.
Мне кажется, что это дало бы (по аналогии с той же Wikipedia) итеративно улучшаемые (в пределе — идеальные) самостоятельные тематические кусочки кода.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, GlebZ, Вы писали:
GZ>>Сразу хочется сказать...
ЗХ>В общем, из всего этого можно сделать вывод, что по крайней мере тебе Codepedia не нужна
В том виде который ты предложил нет. Хотя я сообщение написал не подумавши. Мне очень не понравилось направленность на Unit тесты. Я делал вещи, которые unit тестами и не опишешь. И есть вещи, в которых оценка unit тестами ничего не даст. Ну например реализации языка. Его покрытие unit тестами — процесс бесконечный.
Что мне не нравится. В wikipedia будут готовые классы. Они написаны не языком который предпочитаю я. Они будут не в форме, которую предпочитаю я. Это будут чужие классы, которые мне нужно будет встраивать. Иногда на адаптацию уходит больше времени чем на написание. Я лучше напишу сам. К тому-же, часто для функциональности пишут громадные классы. И в них придется искать нужную тебе функциональность? Мне же нужны how-to. MSDN в плане поиска информации меня неудовлетворяет ни по навигации, ни по содержанию. Фиг вспомнишь в какой ветке contents лежит интересующий тебя материал. Иногда материал по одной и той же библиотеке лежит в разных разделах. Поиск, дурацкий. Среди 500 ответов попробуй найти свой. И он не полон, потому как библиотек значительно больше чем в MSDN. Но ведь нет ничего более полезного чем пример использования библиотеки.
Что бы мне хотелось. Мне хотелось иметь сборник примеров использования. Мне бы хотелось иметь ясный сборник особенностей тех или иных библиотек. И не в форме статей, в которых будешь искать нужный параграф на сотне прокруток экрана, а в форме заметок и экзамплов. Мне не нужно чтобы этот код работал, мне нужно чтобы он был правильным. Правильность, как и в wiki, определяет общественность. И я смогу адаптировать под свое решение так как я хочу.
И самое главное, интуитивное нахождение информации. То есть, правильная навигация. Она тоже должна быть обсуждаемая(до определенных пределов, конечно).
С уважением, Gleb.
PS ну вот, сейчас более правильно высказался.
DG>>Структуризации — нет, ЗХ>Ну, вообще-то категории там есть.
категории — это лишь один из инструментов структуризации
DG>>поддержки нескольких точек зрения — нет, ЗХ>Мммм... Мне кажется, для энциклопедии правильный подход — именно используемый в Википедии NPOV (Neutral Point Of View)
В идеале — да.
но на горячие (на flame-овые) темы — обычно NPOV не бывает.
ЗХ>Хотелось бы заметить, что это все-таки энциклопедия, а не "путеводитель по миру". Цель энциклопедии — отвечать на вопрос "что такое <понятие>", а не организовывать весь мир в логическую структуру.
"что такое понятие" — это скорее роль толкового словаря, а не энциклопедии.
роль энциклопедии — это уже именно структурирование информации.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Хотелось бы заметить, что это все-таки энциклопедия, а не "путеводитель по миру". Цель энциклопедии — отвечать на вопрос "что такое <понятие>", а не организовывать весь мир в логическую структуру.
Приведи примеры понятия в контексте описанной системы. И каким образом пользователь сможет понять, что именно это понятие ему нужно.
Здравствуйте, DarkGray, Вы писали:
ЗХ>>Хотелось бы репозиторий кода, основанный на принципах Wikipedia.
DG>в чем отличие, от http://sourceforge.net, например?
гхм... вроде объяснил уже
1. единица информации — не библиотека, а кусочек кода, который можно охватить взглядом.
2. сниппеты может править кто угодно в любое время.
DG>допустим Codepedia уже есть, какие кусочки кода ты хотел бы там видеть?
Вот это уже по делу вопрос.
В теории — те, которые соответствуют (1) — лаконичные решения повседневных задач. Сверхцель — чтобы, как только у меня возникает некая "типовая" задача (типовая == с большой вероятностью, эту задачу уже неоднократно решало великое множество программистов) наиболее естественной мыслью было бы — пойду возьму codepedia.
На практике... Т.е. чтобы примеры привести... Вообще, надо в rsdn.src покопаться но в общем:
* простые абстракции — математические, баз данных, регекспов, и т.д. и т.п.
* платформ-специфик вещи: скажем, простенький код для работы с tray icon или hook...
...ммм... чего-то такое.
(Вообще говоря, часть буста стоило бы раздербанить на такие вот "сниппеты" — это просто другой подход, не "большая библиотека, в которой есть все — стоит только заинклудить", а "место где можно взять типовой код решения такой задачи, вылизанный до белизны")
Здравствуйте, DarkGray, Вы писали:
DG>>>Структуризации — нет, ЗХ>>Ну, вообще-то категории там есть. DG>категории — это лишь один из инструментов структуризации
а какие нужны еще?...
DG>>>поддержки нескольких точек зрения — нет, ЗХ>>Мммм... Мне кажется, для энциклопедии правильный подход — именно используемый в Википедии NPOV (Neutral Point Of View) DG>В идеале — да. DG>но на горячие (на flame-овые) темы — обычно NPOV не бывает.
горячие головы можно остудить баном или запретом редактирования статьи...
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>В теории — те, которые соответствуют (1) — лаконичные решения повседневных задач. Сверхцель — чтобы, как только у меня возникает некая "типовая" задача (типовая == с большой вероятностью, эту задачу уже неоднократно решало великое множество программистов) наиболее естественной мыслью было бы — пойду возьму codepedia.
ЗХ>На практике... Т.е. чтобы примеры привести... Вообще, надо в rsdn.src покопаться но в общем: ЗХ>* простые абстракции — математические, баз данных, регекспов, и т.д. и т.п.
Имхо, такие вещи должны входить в стандартную библиотеку языка. В Java, .Net, Python, Perl, Ruby так и есть. Это просто исторически так сложилось, что у C/C++ со стандартными библиотеками беда.
ЗХ>* платформ-специфик вещи: скажем, простенький код для работы с tray icon или hook... ЗХ>...ммм... чего-то такое.
ЗХ>(Вообще говоря, часть буста стоило бы раздербанить на такие вот "сниппеты" — это просто другой подход, не "большая библиотека, в которой есть все — стоит только заинклудить", а "место где можно взять типовой код решения такой задачи, вылизанный до белизны")
По поводу раздербанивания boost-а -- это
А вот Ruby community себе подобные вещи сделала: RubyGems и RAA — Ruby Application Archive. Правда поиска по исходникам там нет, но вот идея у RubyGems здравая -- можно загрузить тот пакет, который тебе нужен. При этом RubyGems проверит и, при необходимости загрузит, нужные зависимости, автоматически запустит unit-тесты, сгенерирует RDoc-документацию (аналог Doxygen и JavaDoc).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
В связи с этим прокомментирую ваши мысли:
ЗХ>Единица хранения ЗХ>Один snippet — это некий набор единиц языка (классов, функций), не зависящий от сторонних библиотек (кроме стандартной библиотеки данного языка), служащий однозначно формулируемой цели, и могущий быть использованным "как есть", без переделки.
IMO, Snippet не должен быть больше одной функции по размерам. Ни в коем случае не C++-проект, как на CodeProject!!!
Все, что больше одной функции — называется "библиотекой" и должно удовлетворять всем требованиям библиотеки.
ЗХ>Поскольку однозначного имени (по которому любой программист его найдет) snippet'у дать нельзя, ему дается краткое описание и набор тегов (соответственно, поиск сниппета на сайте — отбор по тегам).
IMO, описание должен исправлять только модератор, набор тегов — любой желающий (с постмодерацией).
ЗХ>Редактирование snippets ЗХ>Редактировать сниппет может кто угодно.
IMO, редактировать сниппет должен создатель (прочитав комментарии) или модератор, или доброволец, при необходимости. ЗХ>Для редактирования сниппета сайт должен предоставлять полноценный редактор кода (подсветка, автоотступ, сворачивание веток, autocomplete стандартной библиотеки).
Последнее требование сводит на нет возможность реализации в обозримом будущем всей затеи.
Возможно, лучше было бы автовыравнивание по выбранным стандартам кодирования при отправлении кода. ЗХ>Необходимо ввести сниппет и юнит-тест на него (код выполняющий проверку корректности сниппета и одновременно — демонстрацию его возможностей).
IMO, юнит-тесты в случае "snippet порядка размера функции" не нужны вообще — ведь любой может откомментировать snippet и указать его ошибки и на что исправить этот код. ЗХ>После этого сервер выполняет проверку.
На хостинге компиляторы размещать? ЗХ>Проверяется: синтаксис и компилируемость кода, стиль (на сервере существуют некоторые правила, типа длины имен переменных и прочая); выполняется юнит-тест. Результатом выполнения юнит-теста является список тестов, которые код прошел/не прошел, а так же (в идеале) покрытие кода тестами (какие классы/функции в выполнении юнит-теста задействованы не были). ЗХ>Код, не прошедший проверку на компилируемость, запостить нельзя. Код, не прошедший критические тесты, запостить нельзя. Код, не прошедший некритические тесты, запостить можно, в каталоге он будет показан как "сниппет такой-то — проходит 80% тестов".
Это был план развития сайта на следующие 10 лет
А вот из того, что можно быстро осуществить — это рейтингование snippets и возможность рейтингования комментариев как "важных".
IMO, комментарии обязательны и желательно должны быть древовидными. Из-за линейности комментариев и присутствующего там флейма и оффтопика потом ничего не разобрать. ЗХ>Поиск и выбор snippets ЗХ>Поиск идет по тегам и просто через поисковую систему. [далее пропущен тяжелоосуществимый бред]
IMO, хороший поиск и индексирование сайта поисковыми системами обязательно.
Также обязательным является кластеризация. Она не обязательно должна быть навороченной, главное, чтобы она стремилась к тому, что один snippet попадал в одну категорию. Так, для начала разделов 5 будет вполне достаточно.
В этом плане юзабилити koders.com и ru.livecode.org очень низкое, что и определяет степень их использования разработчиками. Сайт, который будет активным, должен быть открытым и для поисковиков.
Обязательно должна быть возможность прийти на сайт из интернета, набрав в поисковике нужный запрос, и попасть сразу на страницу примера. Пример: поищите в google "php open file" — наглядный пример, как все должно работать.
Еще пример. RSDN подкачал. Пример: поищите "rsdn getdllversion" или "site:www.rsdn.ru getdllversion" — и где тут сообщения могучего форума RSDN по данной теме? Более того, отмазка "ищите в поиске на rsdn" оказывается неконструктивной. Я пользуюсь каждый день как минимум десятком сайтов. Стоит ли мне запоминать, в каком месте на каждом сайте расположен запрос поиска, и потом мучиться с его убогой, или просто особенной сортировкой в результатах выдачи? (Честно говоря, именно из-за плохого поиска и появляются сообщения, которые уже на 20 раз обсуждались — человеку проще задать вопрос, чем найти его)
ЗХ>Административное устройство ЗХ>По всей видимости, кроме модераторов (чья функция — как всегда — пресекать хулиганство и вандализм) нужны maintainers (добровольцы-энтузиасты), которые станут более-менее регулярно просматривать новые и измененные сниппеты, выбрасывать никому-не-нужные, рефакторить плохо-написанные и т.п.
IMO, maintainers — это и есть модераторы, а твои модераторы — это администраторы...
ЗХ>На закуску — проблемы реализации ЗХ>Крутейшая среда с рефакторингом и веб-интерфейсом, серверная, выдерживающая дикие нагрузки — это не шубу в трусы заправить. Других проблем не видать Возможно, нагрузку можно каким-то образом перенести на клиента (скачивается программа, в которую уже встроен редактор; каким-то образом полагаться на установленный у клиента компилятор, и т.п.). JetBrains, ау?!
Это был самый настоящий бред. Советую поискать бритву Оккама, она должна у вас быть где-то поблизости.
IMO, форма с подсветкой кода и автовыравниванием после нажатия кнопки "preview" будет смотреться замечательно.
А легкий submit без обязательной постмодерации (но только для зарегистрированных пользователей!) — необходимое условие для быстрого пополнения сайта.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>1. единица информации — не библиотека, а кусочек кода, который можно охватить взглядом. ЗХ>2. сниппеты может править кто угодно в любое время.
Здравствуйте, AndrewVK, Вы писали:
ЗХ>>1. единица информации — не библиотека, а кусочек кода, который можно охватить взглядом. ЗХ>>2. сниппеты может править кто угодно в любое время.
AVK>Простой вопрос — а чем это отличается от VCS?
Ну, если по всему этому топику непонятно — то я не знаю как объяснить.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>>1. единица информации — не библиотека, а кусочек кода, который можно охватить взглядом. ЗХ>>>2. сниппеты может править кто угодно в любое время.
AVK>>Простой вопрос — а чем это отличается от VCS?
ЗХ>Ну, если по всему этому топику непонятно — то я не знаю как объяснить.
Нет, непонятно. Все, о чем ты говоришь, реализуется нормальной VCS + стандартом на метеданные кусков кода + возможно специализированным клиентским софтом. По любому удобнее wiki.
Здравствуйте, Зверёк Харьковский, Вы писали:
AVK>>....По любому удобнее wiki.
ЗХ>Ты вообще отвергаешь идею вики? (не для редактирования кода, а в целом)
Идеологически разницы между wiki и VCS + публикатор нет. Однако VCS обеспечивает куда больше сервиса, да и редактировать на локальной машине проще.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>....По любому удобнее wiki.
ЗХ>>Ты вообще отвергаешь идею вики? (не для редактирования кода, а в целом)
AVK>Идеологически разницы между wiki и VCS + публикатор нет. Однако VCS обеспечивает куда больше сервиса, да и редактировать на локальной машине проще.
Мммм... Разница, имхо, все же есть.
Юз-кейс vcs: засасываем на локальную машину весь проект, работаем с ним, закидываем на сервер обновления.
Юз-кейс wiki: бродим по содержимому сервера, рассматриваем его, если что-то "не понравилось" — выполняем in-place редактирование.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Мммм... Разница, имхо, все же есть. ЗХ>Юз-кейс vcs: засасываем на локальную машину весь проект, работаем с ним, закидываем на сервер обновления.
1) Совсем не обязательно весь.
2) Для просмотра вобще не надо ничего явно засасывать (см. например RepoBrowser в Subversion, или то, что кажет SVN-сервер по http-протоколу, есои зайти браузером)
ЗХ>Юз-кейс wiki: бродим по содержимому сервера, рассматриваем его, если что-то "не понравилось" — выполняем in-place редактирование.
Все то же можно сделать и в случае VCS, вопрос в инструменте. Браузер в любом случае очень плохо подходит для редактирования кода (его как минимум один раз нужно скомпилировать и запустить).
Здравствуйте, AndrewVK, Вы писали:
ЗХ>>Юз-кейс wiki: бродим по содержимому сервера, рассматриваем его, если что-то "не понравилось" — выполняем in-place редактирование.
AVK>Все то же можно сделать и в случае VCS, вопрос в инструменте.
Тогда это будет wiki, реализованная поверх VCS Насколько я помню, такие штуки где-то видел
AVK>Браузер в любом случае очень плохо подходит для редактирования кода (его как минимум один раз нужно скомпилировать и запустить).
Если внимательно почитать исходное сообщение, там это учтено.
DG>>>>Структуризации — нет, ЗХ>>>Ну, вообще-то категории там есть. DG>>категории — это лишь один из инструментов структуризации
A>а какие нужны еще?...
Отношение частное — общее,
отношение целое — части,
порядковые отношения,
и т.д.
DG>>>>поддержки нескольких точек зрения — нет, ЗХ>>>Мммм... Мне кажется, для энциклопедии правильный подход — именно используемый в Википедии NPOV (Neutral Point Of View) DG>>В идеале — да. DG>>но на горячие (на flame-овые) темы — обычно NPOV не бывает.
A>горячие головы можно остудить баном или запретом редактирования статьи...
дык проблема не в самом flame-е, а в том, что NPOV на данный момент просто нет, т.к. проверить, чья точка зрения правильнее — можно будет проверить когда-то потом.
ps
вот, что, например, писать про астрологию?
что это лженаука, или что это наука?
а ведь что не напиши, другие обидяться.
DG>>>>>Структуризации — нет, ЗХ>>>>Ну, вообще-то категории там есть. DG>>>категории — это лишь один из инструментов структуризации
A>>а какие нужны еще?...
DG>Отношение частное — общее, DG>отношение целое — части, DG>порядковые отношения, DG>и т.д.
Проблема сложной структуризации — в том, что она очень тяжело поддерживается силами самих пользователей.
DG>дык проблема не в самом flame-е, а в том, что NPOV на данный момент просто нет, т.к. проверить, чья точка зрения правильнее — можно будет проверить когда-то потом.
DG>ps DG>вот, что, например, писать про астрологию? DG>что это лженаука, или что это наука? DG>а ведь что не напиши, другие обидяться.
Здравствуйте, nzeemin, Вы писали:
N>Посмотри вот это: N>http://ru.livecode.org/index.php/Заглавная_Страница N>- человеком двигали вполне благие намерения. И движок там от Википедии (Медиавики). А получилось черти что. А все почему? Потому что (i) не надо распыляться и пытаться охватить все на свете и (ii) очень важна грамотная классификация/категоризация.
Хм... а что именно там "черти что"? На первый беглый взгляд достаточно интересный проектик и почти то, что Зверек описывал.
Здравствуйте, Зверёк Харьковский, Вы писали:
AVK>>Все то же можно сделать и в случае VCS, вопрос в инструменте.
ЗХ>Тогда это будет wiki, реализованная поверх VCS
Неа. VCS намного круче чем wiki. Это вики такая куцая м примитивная VCS.
AVK>>Браузер в любом случае очень плохо подходит для редактирования кода (его как минимум один раз нужно скомпилировать и запустить).
ЗХ>Если внимательно почитать исходное сообщение, там это учтено.
страница типа "страницы ссылающиеся на эту страницу"... не совсем то, но...
DG>отношение целое — части,
ссылки внутри статьи на более подробное описание некоторых терминов... все таки гипертекст...
DG>порядковые отношения, DG>и т.д.
DG>дык проблема не в самом flame-е, а в том, что NPOV на данный момент просто нет, т.к. проверить, чья точка зрения правильнее — можно будет проверить когда-то потом. DG>ps DG>вот, что, например, писать про астрологию? DG>что это лженаука, или что это наука? DG>а ведь что не напиши, другие обидяться.
с этим примером все просто, здесь используется точка зрения официальной науки...
Здравствуйте, 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[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 результата?...
К сожалению, на рсдн пост был воспринят не совсем верно — вместо обсуждения идеи — критика несущественных частей предполагаемой реализации. Попробуем исправить ситуацию 
) и рсдн-овский трафик в дальнейшем 
, это уж звиняйте, зато рабочий и используемый ( Пусть кричат "Уродина!" А она нам нравится! Хоть и не красавица!
Более того, отмазка "ищите в поиске на rsdn" оказывается неконструктивной. Я пользуюсь каждый день как минимум десятком сайтов. Стоит ли мне запоминать, в каком месте на каждом сайте расположен запрос поиска, и потом мучиться с его убогой, или просто особенной сортировкой в результатах выдачи? (Честно говоря, именно из-за плохого поиска и появляются сообщения, которые уже на 20 раз обсуждались — человеку проще задать вопрос, чем найти его)
