Здравствуйте, Sinix, Вы писали:
S>1. У вас студия запрещена что ли 
Ваш boilerplate уже лет 8 подставляется автоматом
Мне пофиг, кто и как вставляет юзинги — тут вопрос принципа минималистичности. Если у компилятора достаточно информации для работы, я не должен ему ещё тыкать "возьми там, положи здесь". С таким успехом можно и на ассемблере фигачить — а вдруг C# компилятор неправильно поймёт "add"?
И юзинги не только мешаются в шапке, об них постоянно спотыкаешься в коде — вместо набора fi->выбрал "File" я руками набираю весь класс, после чего студия любезно предлагает добавить нэймспэйс — оно мне надо?
S>2. Это классика проектирования сложных систем: любое новое поведение должно добавляться как opt-in, а не как opt-out.
S>Другими словами, хочешь что-то заиспользовать — будь любезен объявить это явно.
Фигня, всего лишь костные привычки от языков старого формата. Да и "неявного" тут ничего нет — все неизвестные/неоднозначные классы всплывут походу.
S>И да, раскидыванием по библиотекам эта проблема не решается, классика:
S>S>// Assembly A, references ANode
S>Node Parse(...) { ... }
S>// Assembly B, references BNode
S>Node Parse(...) { ... }
S>// Assembly B, some helper
S>string SomeHelper(...) { ... }
S>
S>В проекте везде используются типы из A, используем хелпер из B. Автореференсы засирают лог сборки несколькими тысячами однотипных ошибок, приятной отладки 
Для начала стоит сказать, что и с юзингами отладка одинаковых имён — тот ещё гемор, тут бестолковость _разработчика_, которая к языку не имеет никакого отношения.
Далее, "классика"? Тю, обычный пример из пальца. Разбираем: есть проект C, который юзает две ассембли A и Б, причём в каждой есть класс Узел. Как только мы касаемся Узел в исходнике C/util.cs, сразу попадаем на неоднозначность:
var n = new Node();
...которую тут же легко подправляем:
alias Node = AssemblyB.Node;
var n = new Node();
SomeHelper(n);
Причём alias нужен исключительно для упомянутых в коде классов. Более того — нужный класс Узел может даже быть ВЫВЕДЕН из использования в SomeHelper(n)!
Откровенно, я ещё не видел такого УЖАСНОГО проекта, где два исходника содержат два "разных" Узла и весь этот кошмар юзается в третьем проекте! Ваш высосанный пример только лишний раз доказывает, что проблема сидит в прокладке меж монитором и клавой, нежели в каких-то именах.
Нэймспэйсы нужны — они делают свою работу за кадром, но опускаться до уровня "возьми вот эту либу" — это перекладывать лень разработчиков компилятора на тысячи плеч программистов.
Возможно, проблема не была бы столь надоедливой, если бы филоны из VS team почаще отрывали задницы от кофейных сидений — в студии ДОФИГА всего надо улучшать, а они там иконки перекрашивают! Хотя б собирали для начала имена всех полезных классов, чтоб я не парился с вводом. Но полезность юзингов всё равно остаётся для меня сомнительной.
K>>Про конфликт имён — очевидно и первоклашке, using нужен, но лучше как ключевое слово alias.
S>3. Юзинги в проекте порождают ещё более забавную проблему с включением в проект чужих исходников. Блин, да даже стандартный сценарий "перетаскиваем файл из проекта в проект" после такого пожелания превращается в минное поле.
Ничуть. Проект — это тебе не свалка, в нём не должно быть ИСХОДНИКОВ, которые ты не касаешься. Кажется, я догадываюсь, откуда берутся проекты, компилящиеся по 30 минут — вот-вот, те самые "кучи г-сходников", которые включают наобум.
Нужна либа? Скомпилял дебаг-версию, подключил, забыл. И конфликтов имён никаких.
Здравствуйте, namespace, Вы писали:
N>Да, я понял Вашу идею, и она мне абсолютно не нравится.
Не спорьте. Посмотрите остальные посты топикстартера, он с непонятным упорством пытается троллить на темы, в которых явно и очевидно не разбирается.
Ладно бы в КСВ, но в профильных ветках так подставляться — эт уже перебор
Здравствуйте, Kolesiki, Вы писали:
K>За 10 лет шарпенины
С самой школы, что ли, считаешь?
