Сделал промежуточный сброс по второй версии диапазонов. На код пока смысла смотреть не имеет — в процессе очень активного допиливания. Никаких гарантий от слова совсем.
Исправления по основной ветке:
1. Добавил настройки для форматирования XmlComments. Старался сделать так, чтобы они совпадали с стандартными по всему проекту, т.е изменения быть не должно.
Если что не так — смело правьте. Форматирование запускается только из Cleanup, автоформат (по крайней мере на EAP) xml comments не форматирует.
В список cleanup добавил CodeJam Cleanup. Только форматирование кода. По возможности его настройки не менять, иначе cleanup начинает слишком много брать на себя
2. Поправил опечатки по коду. Кто использует решарпер — ставим ReSpeller Free, кто не использует — вот это расширение. Для решарпероводов — не забываем добавлять слова, которых нет в словаре в общий словарь (add custom word to user dictionary... -> SaveTo -> Solution team-shared).
3. Убрал лишнюю перегрузку CodeExceptions.ArgumentOutOfRange с одним from. Ненужна(tm). Оформлено отдельным коммитом
Revision: 38559cc1878def2b465fcf13873c269d8d6d3b49
Code - removed the unused overload
Если надо — этот коммит можно перетащить в ветку релиза.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос — а зачем в RangeBoundaryKind отдельно FromXxx/ToXxx? Какой в этом практический смысл кроме возможности создания диапазонов задом наперед?
Идея такая: RangeBoundary хранит полную информацию о границе диапазона — правая/левая, +/- бесконечность, включает/не включает значение.
Нужно для того, чтобы можно было сравнить две границы, не таская за ними сам диапазон.
Причин почему так сделано куча, из того, что вспомнил:
1. Из соображений производительности скорее всего придётся вводить два диапазона — один обычный, второй — с ассоциированным ключом (значением).
Второй нужен для операций из значений сгенерил дипазоны — объединил/пересёк/поменял — вытащил исходные значения.
Чем больше кода удастся вытащить в сами границы — тем проще будет эту пару поддерживать.
2. Большинство алгоритмов типа поиска всех возможных пересечений работают именно с границами диапазонов. И для некоторых важен тип границы, хотя бы потому что иначе Distinct перестаёт работать.
3. Если объединить пары FromXxx/ToXxx, то как минимум перестанет работать:
* сравнение ToExclusive с FromExclusive. Ну, т.е. диапазон "от двух исключительно до двух исключительно" станет легальным.
* .ToString()
Если не срочно — подожди плиз неделю. Как добью enum-ы (в процессе) — переключусь на диапазоны обратно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос — а зачем в RangeBoundaryKind отдельно FromXxx/ToXxx? Какой в этом практический смысл кроме возможности создания диапазонов задом наперед?
И огромная просьба — не трогать код диапазонов пока
У меня дома пачка несброшенных коммитов, мелочи ещё можно смержить, что покрупнее — манал я такое счастье
Здравствуйте, Sinix, Вы писали:
S>3. Если объединить пары FromXxx/ToXxx, то как минимум перестанет работать: S>* сравнение ToExclusive с FromExclusive. Ну, т.е. диапазон "от двух исключительно до двух исключительно" станет легальным.
Мне кажется что возможность запихнуть ToXxx во From границу намного хуже.
Ну и вообще какое то сомнительное решение. Перформанс онот может слегка и уучшает, но ценой ухудшения удобства использования.
S>Если не срочно — подожди плиз неделю. Как добью enum-ы (в процессе) — переключусь на диапазоны обратно.
Да мне оно особо без надобности. Просто вызвало вопросы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Мне кажется что возможность запихнуть ToXxx во From границу намного хуже.
Оно валидируется ассертами. Не помню, есть это в коде или не скинул ещё. На перфоманс влияет в границах статпогрешности, в коде эти ассерты не срабатывают — API правильно сделано.
Скинута четверть где-то, даже меньше, нечего пока обсуждать
AVK>Ну и вообще какое то сомнительное решение. Перформанс онот может слегка и уучшает, но ценой ухудшения удобства использования.
Ну вот есть у тебя диапазоны a = [2..3) и b = (3..4]. В текущем дизайне a.To < b.From вернёт true.
В твоём варианте — false, т.к. они равны.
Я все эти варианты уже перепробовал, текущий подход — это то ли 3 то ли 4 итерация уже.
На практике получается или делаем сравнение границ математически корректным, или весь код превращается в кучу подпорок чтоб сравнения работали.
Здравствуйте, Sinix, Вы писали:
AVK>>Мне кажется что возможность запихнуть ToXxx во From границу намного хуже. S>Оно валидируется ассертами. Не помню, есть это в коде или не скинул ещё. На перфоманс влияет в границах статпогрешности, в коде эти ассерты не срабатывают — API правильно сделано.
Асерты это костыли.
AVK>>Ну и вообще какое то сомнительное решение. Перформанс онот может слегка и уучшает, но ценой ухудшения удобства использования. S>Ну вот есть у тебя диапазоны a = [2..3) и b = (3..4]. В текущем дизайне a.To < b.From вернёт true. S>В твоём варианте — false, т.к. они равны.
Я пока никакого варианта не предлагал. Нужно как нибудь отделить то, что пользователю придется в голове держать, и то что не придется.
Если оно тебе в алгоритмах нужно — задай два енума — один для передачи в конструктор, второй для хранения, заодно выкинув и Empty, который тоже изрядно невалидных инвариантов порождает. Или, если нескольких байт не жалко — заведи в RangeBoundary флажок From/To. Главное, чтобы дизайн при первом же взгляде не вызывал WTF.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinix, Вы писали:
AVK>>Так сбрасывай, смысл их мариновать? S>Ну вот как дойдёт очередь — скину. Сам попросил сначала Enum-ы быстро добить
Я не просил сначала, я просто напомнил.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK> Главное, чтобы дизайн при первом же взгляде не вызывал WTF.
Договорились, как скину целиком — попрошу посмотреть. Иначе фигню обсуждаем
