Здравствуйте, IT, Вы писали:
AVK>>Но неудобно.
IT>Тебе может и не удобно. Или ты этот проект затеял исключительно для себя?
А ты готов утверждать, что твой вариант удобнее для большего количества людей, нежели мой?
IT>Тем не менее MS не часто отходит от правила "один неймспейс — один фолдер".
Ты это как вообще выяснил? МС то до недавнего времени вообще исходники в собираемом виде не выкладывал. А в том что сейчас выложил — розлин я тебе уже показал. Вот тебе WCF —
https://github.com/dotnet/wcf/blob/master/src/System.Private.ServiceModel/src/Internals/FxTrace.cs . Вот CoreClr —
https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/AppContext/AppContext.cs, DocFx —
https://github.com/dotnet/docfx/blob/dev/src/Microsoft.DocAsCode.Common/Loggers/ILogItem.cs. По большому счету, тупое следование структуре неймспейсов с кучей пустых каталогов есть только в CoreFx.
IT>А я считаю это самым натуральным бардаком. В библиотеке 3 класса, а найти что-нибудь в ней может только тот, кто их писал. Афигенный порядок.
Ты преувеличиваешь.
IT>>>1. Мы делаем не конечный продукт на который никогда не появлится не одного референса, а библиотеку общего назначения.
AVK>>Еще раз — пользователям библиотеки насрать на организацию файлов по каталогам.
IT>Пока, глядя не нелогичность структуры проекта
Структура логична, просто там не та логика, которую ты привык видеть.
IT>Объясняю. Ограничения существуют, чтобы им следовали, не обязательно жёстко, но следовали.
Зашибись. Нет уж, ограничения нужны чтобы получать от них какую то пользу, а не просто им следовать. Иначе получается "если вы такие умные, то почему строем не ходите".
IT> А для тебя похоже они существуют исключительно, чтобы их сразу нарушать.
Нет. Уж ты то должен бы помнить, что я вообще большой любитель порядка в коде. Я даже написал небольшой документик, там 6 ограничений уже указано, из них 4 строгих. А вот конкретно идея со знаком равенства между каталогом и немспейсом мне категорически не нравится. Не потому что я вообще против, а потому что попробовал сие на практике и сделал выводы.
IT>>>В CodeJam.
AVK>>Почему именно туда?
IT>А что здесь непонятног?
Ну, правило твое как ты его сформулировал ничего про этот не говорит.
IT>>>Всё касающееся коллекций в CodeJam.Collections.
AVK>>А почему не в CodeJam.Collections.Generic?
IT>Можно и туда, но думаю, CodeJam.Collections достаточно.
Думаешь? А можно ход твоих дум? Ну чтобы я тоже мог правильным образом думать, а не только у тебя консультации спрашивать.
AVK>>Я тут еще одну прекрасную вещь про много неймспейсов вспомнил. Ты же помнишь, что называть класс так же, как и часть неймспейса мягко говоря не рекомендуется?
IT>Не помню.
Ну вот теперь помнишь. В результате, когда у тебя некая сучность имеет одно устоявшееся название, и этой сучности соответствует какой нибудь класс, то придумывание неймспейса для нее превращается в увлекательнейший аттракцион "догадайся что я имел в виду".
AVK>>А что такое Linq формально? Вот Concat который у нас — это LINQ? А DisposeAll это LINQ?
IT>Чего эти классы хелперы?
А вот интересный вопрос. У Concat еще ладно — можно формально отнести к IEnumerable. А вот у второго — IEnumerable<IDisposable>. Куда его, в collections или в корень?
AVK>>Пример розлина я уже приводил.
IT>В том примере три класса по 20 строчек и один неймспейс.
Так это вообще то типичная ситуация. Бывает даже что класс один, а файлов несколько потому что класс на несколько кусков разрезан ввиду его размеров. Если кусков штук 5 — логично все такие куски засунуть в подкаталог, нет?
IT>Посмотрел. Похоже в CmdLine неслабый монстрик зарождается. Там делов максимум на 200 строк кода
Исходя из требования декларативного описания схемы — в 200 строк кода ты ну никак не впихнешь. Да и функционал там пока что сильно зачаточный, многого не хватает.
IT>Кстати, от подобной практики, когда модель убирается в отдельную папку я уже давно отказался даже в WPF. На практике крайне не удобно бегать из папки в папку, работая по сути над одной и той же вещью.
Это осталось от R.SAT где оно вообще в разных проектах было. А сейчас это просто группировка, чтобы было понятно что к чему относится. Как раз борьба с тем самым бардаком, который тебе так активно не нравится.
IT>Я вообще не вижу смысла разбивать расширения со строками и символами на пять файлов.
Смысл в несоздании монстрофайлов — с большими файлами неудобно работать.
IT> Всё можно поместить в один, а группы методов разделаить регионами и, опаньки, проблема с папкой исчезает сама собой.
Зато появится пачка других — тормозящий решарпер/розлин, увеличенная вероятность конфликтов, усложнение одновременной работы с двумя частями внутри одного файла и т.п.
IT>Да бардак уже есть.
Нету.
IT> При этом базируется он на твоих рассуждениях. в которых я никак не уловлю логики. С одной стороны ты говоришь, что у нас в проекте классов будет немного, поэтому неймспейсы не нужны.
Я не говорю что неймспейсы нам не нужны. Я говорю о том, что:
1) Заводить отдельный неймспейс для всех расширений как ты предлагал — точно хрень
2) Заводить много неймспейсов — неудобно в использовании, так как порождает тучу ненужных юсингов и сильно ухудшает discoverability библиотеки. А для нас это очень важно, так как библиотека не на одном аспекте сфокусирована, а наоборот, предполагает очень широкий спектр функционала.
3) Заводить неймспейс только потому что мне захотелось сгруппировать несколько файлов в один каталог — бессмысленная имитация бурной деятельности, еще к тому же, как ты правильно заметил, ломающая совместимость в перспективе.
При этом я совершенно не против разумного добавления неймспейсов. К примеру, CodeJam.CmdLine, CodeJam.TableParsers, CodeJam.Threading точно выглядят разумно. А вот создание неймспейса CodeJam.TableParser.Csv.Escaped или пихание всех парсеров в один каталог мне разумным не кажется.
IT>Короче. Обсуждать это я больше не намерен, т.к. похоже, что стороны пришли к взаимному несогласию и дальшее обсуждени лишено всякого смысла. Делай как считаешь нужным.
Ну, как минимум тебе стоит описать ход своих мыслей достаточно подробно. Вариант "я так думаю" плохо воспроизводим.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>+ boost::optional<T>
Просто праздный интерес — для тебя настолько важно, что это есть в бусте, что ты не поленился написать отдельное сообщение?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
EP>>+ boost::optional<T>
AVK>Просто праздный интерес — для тебя настолько важно, что это есть в бусте, что ты не поленился написать отдельное сообщение?
Ты ведь изначально сказал:
EP>>В C++ есть первый вариант — Boost.
AVK>Спорно. В бусте много шлака. Ну и с С++ ситуация сильно другая, не надо его практики на дотнет переносить.
В итоге шлак так и не показал, совершил какие-то невнятные наезды на строки и Lambda, а в итоге именно Boost'овские практики и переносятся
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В итоге шлак так и не показал, совершил какие-то невнятные наезды на строки и Lambda, а в итоге именно Boost'овские практики и переносятся
А, опять флейм на тему С++ лучше дотнета? Ну, как то так я и думал.
P.S. Я не говорил, что в бусте нет полезного вообще.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>А, опять флейм на тему С++ лучше дотнета? Ну, как то так я и думал.
Нет, флеймить на эту тему не хочу, и он не лучше — они разные, для разных задач. Мне просто непонятна эта аллергическая реакция на изначальное упоминание Boost
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Нет, флеймить на эту тему не хочу, и он не лучше — они разные, для разных задач. Мне просто непонятна эта аллергическая реакция на изначальное упоминание Boost
Тебе показалось. Не было никакой аллергической реакции.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Кому интересно — в официальный nuget фид выложена первая пререлизная версия. Искать по CodeJam.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Beta 3 is out. Основной функционал почти стабилен, можно уже начинать использовать.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
