За 10 лет шарпенины я встречался, ну, может быть, раз 5 с ситуацией, когда имена классов разных библиотек совпадали (соотв. использовал using alias). Зачем такая малопрактичная хрень возведена аж в стандарт языка?? Или это тупое копирование идей из жабы, с которой C# был слизан чуть менее, чем полностью? На мой взгляд, куда практичнее было бы использовать некий "набор библиотек", подходящий для данного типа приложения (WinForms, WPF, Office add-in, etc), и указываемый в проекте, а не засоряющий мои листинги.
Конечно, есть ещё "программы одного файла", но опять же — никто не мешает компилеру иметь где-то в дефолтах список либ, которые нужно подключить (или указывать их в командной строке).
В общем, идея понятна — не засорять листинги тем, что весьма косвенно относится к алгоритму.
Что скажете?

K>На мой взгляд, куда практичнее было бы использовать некий "набор библиотек", подходящий для данного типа приложения (WinForms, WPF, Office add-in, etc), и указываемый в проекте, а не засоряющий мои листинги.
Ну и как бы Вы добавили две [сторонние] либы, содержащие классы с одинаковым названием?

Для программиста с десятилетним опытом на шарпе, это очень странные вводы. Или Вы не выразили свою мысль до конца и у Вас есть идеи по изоляции таких классов?

Здравствуйте, Kolesiki, Вы писали:

K>В общем, идея понятна — не засорять листинги тем, что весьма косвенно относится к алгоритму.
K>Что скажете?

Что вы не работали на средних или на крупных проектах. Там нарваться на конфликт имён после подключения стороннего кода — раз плюнуть.
Родина шарпа и явы — энтерпрайз.

Для любителей малых форм есть бейсик с default imports, with, case insensitive identifiers, strict off и прочими способами отстрелить ногу водяным пистолетом.
Если хочется такой же, только с фигурными скобочками — вэлкам в яваскрипт

Здравствуйте, namespace, Вы писали:

K>>На мой взгляд, куда практичнее было бы использовать некий "набор библиотек", подходящий для данного типа приложения (WinForms, WPF, Office add-in, etc), и указываемый в проекте, а не засоряющий мои листинги.
N>Ну и как бы Вы добавили две [сторонние] либы, содержащие классы с одинаковым названием?

А что тут запредельного-то? Как-нибудь так:

alias Some.Graphics.Library.Point = MyPoint;

Здесь это именно _синоним_ — никаких "импортов имён" и прочей шелухи.

N>Для программиста с десятилетним опытом на шарпе...

Сэр, у вас рукав в говне, а вы лезете переходить на личности — нетехнически это!

Здравствуйте, Sinix, Вы писали:

S>Что вы не работали на средних или на крупных проектах. Там нарваться на конфликт имён после подключения стороннего кода — раз плюнуть.

Ресь не о конфликте имён (который как раз легко разрешаем, см. выше), а в самой идее писанины кучи директив, которые в большинстве случаев легко устраняются перекладыванием работы на компилер.

K>Сэр, у вас рукав в говне, а вы лезете переходить на личности — нетехнически это!
Я Ваших аллегорий и обиды не понимаю.
Понятно было бы, если бы вы пришли с другого языка и применение using было бы в новинку, или вообще новичок, а так — это все еще остается странным т.к. я таки все еще не понял что Вы предлагаете.
N>>Для программиста с десятилетним опытом на шарпе...
Имелось ввиду, что ожидается какая-то рационализаторская идея или полная глупость. Надеюсь первое, иначе я бы даже не отвечал.

Вам не нравится слово using? Или порядок декларирования алиаса?
Разницы пока не уловил.

using MyPoint = Some.Graphics.Library.Point;

или

alias Some.Graphics.Library.Point = MyPoint;

Если для каждого требуемого класса из пространства имен создавать алиас, то это даже еще больше места займет в коде.

Здравствуйте, Kolesiki, Вы писали:

K>Что скажете?

Скажу что бред. Например вы хотите генерировать отчеты в Word и Excel, внезапно точка входа обоих называется Application. Как их различать, если у вас автоматом все "нужные" библиотеки подключаются? Или как например быть с тем, что имена классов для winform совпадают на 10% с WPF? Причем вполне может быть, что вы будете использовать и одни и другие классы в одном приложении.

Здравствуйте, Kolesiki, Вы писали:

K>Ресь не о конфликте имён (который как раз легко разрешаем, см. выше), а в самой идее писанины кучи директив, которые в большинстве случаев легко устраняются перекладыванием работы на компилер.

Не легко.

Кстати, РеШарпер последних версий делает автоимпорт. С ним пишешь код как будто все импортеры подключены по умолчанию.

Костыль конечно, но проблему решает сносно.

Здравствуйте, gandjustas, Вы писали:

G>Скажу что бред. Например вы хотите генерировать отчеты в Word и Excel, внезапно точка входа обоих называется Application. Как их различать, если у вас автоматом все "нужные" библиотеки подключаются? Или как например быть с тем, что имена классов для winform совпадают на 10% с WPF? Причем вполне может быть, что вы будете использовать и одни и другие классы в одном приложении.

Можно позволить в языке частичную квалификацию (в Немерле поддерживается) и писать так:

Excel.Application _excel;
Word.Application  _excel;

Еще можно иметь некий глобальный для проекта файл где такая неоднозначность будет разруливать:

alias ExcelApp = Excel.Application;
alias WordApp  = Word.Application;

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, gandjustas, Вы писали:

G>>Скажу что бред. Например вы хотите генерировать отчеты в Word и Excel, внезапно точка входа обоих называется Application. Как их различать, если у вас автоматом все "нужные" библиотеки подключаются? Или как например быть с тем, что имена классов для winform совпадают на 10% с WPF? Причем вполне может быть, что вы будете использовать и одни и другие классы в одном приложении.

VD>Можно позволить в языке частичную квалификацию (в Немерле поддерживается) и писать так:
VD>

VD>Excel.Application _excel;
VD>Word.Application  _excel;
VD>

VD>Еще можно иметь некий глобальный для проекта файл где такая неоднозначность будет разруливать:
VD>

VD>alias ExcelApp = Excel.Application;
VD>alias WordApp  = Word.Application;
VD>

Второе и есть using, первое тоже делается через using. Если исходную мысль автора довести до ума, то нужны просто глобальные юзинги на весь проект, чтобы они раз написал и забыл. Примерно как в страницах asp.net.

Здравствуйте, gandjustas,

G> Если исходную мысль автора довести до ума, то нужны просто глобальные юзинги на весь проект, чтобы они раз написал и забыл.

Кхм. А как насчет переиспользования кода?

Здравствуйте, namespace, Вы писали:

N>Ну и как бы Вы добавили две [сторонние] либы, содержащие классы с одинаковым названием?
N>Для программиста с десятилетним опытом на шарпе, это очень странные вводы. Или Вы не выразили свою мысль до конца и у Вас есть идеи по изоляции таких классов?
Опыт бывает сильно разным и от стажа работы он не зависит.
Можно проработать десять лет и не узнать про его существование, а можно применить его за пару месяцев рабочего стажа.

Здравствуйте, Kolesiki, Вы писали:

K>Зачем такая малопрактичная хрень возведена аж в стандарт языка??
"Малопрактичная" с твоей колокольни.

Здравствуйте, VladD2, Вы писали:

VD>Можно позволить в языке частичную квалификацию (в Немерле поддерживается) и писать так:

Решетка поддерживает частичную квалификацию в каком-то виде.

Здравствуйте, gandjustas, Вы писали:

G>Если исходную мысль автора довести до ума, то нужны просто глобальные юзинги на весь проект, чтобы они раз написал и забыл. Примерно как в страницах asp.net.
Нет, он хочет автоимпорт.

Здравствуйте, namespace, Вы писали:

N>Я Ваших аллегорий и обиды не понимаю.
N>Понятно было бы, если бы вы пришли с другого языка...

Суть моего вопроса НЕ ЗАВИСИТ от квалификации вопрошающего — вот где нужен интеллект, чтобы задуматься: а может и правда, нафик эти юзинги?...

N>Разницы пока не уловил.
N>

N>using MyPoint = Some.Graphics.Library.Point;
N>

N>или
N>

N>alias Some.Graphics.Library.Point = MyPoint;
N>

Потому что вы не поняли суть вопроса: я поставил под сомнение саму идею импорта имён (не затрагивая using-as-alias). Вы можете рационально объяснить катастрофическую необходимость в коде каждого файла(!) писать один и тот же boilerplate только для того, чтобы пользоваться всем классическим дотнетом?
Про конфликт имён — очевидно и первоклашке, using нужен, но лучше как ключевое слово alias.

Здравствуйте, gandjustas, Вы писали:

G>Скажу что бред. Например вы хотите генерировать отчеты в Word и Excel, внезапно точка входа обоих называется Application.

Уже давно отвечено: using как синоним остаётся. Я предлагаю лишь автоматизировать чепуху вроде

using System;
using System.Collections.Generic;
using System.Globalization;
using System.Linq;
using System.Threading;
using System.Windows.Forms;

G> Или как например быть с тем, что имена классов для winform совпадают на 10% с WPF?

Да никак — читайте классиков

Kolesiki> куда практичнее было бы использовать некий "набор библиотек", подходящий для данного типа приложения (WinForms, WPF, Office add-in, etc), и указываемый в проекте

G> Причем вполне может быть, что вы будете использовать и одни и другие классы в одном приложении.

Навряд ли. WinFormsHost — может быть, но каша из WPF-WinForms кода — это вы впадаете в экстрим, который не интересен. И опять напомню: alias сохраняется.

Здравствуйте, gandjustas, Вы писали:

G> Если исходную мысль автора довести до ума, то ...

То получится ровно то, что и сказал автор в первом сообщении

использовать некий "набор библиотек", подходящий для данного типа приложения (WinForms, WPF, Office add-in, etc), и указываемый в проекте

Несмотря на кажущуюся глупость и наивность вопроса, я б всё равно задумался — всегда имеет смысл перетряхнуть слежавшиеся устои, доставшиеся нам от жабоводов, сипиписников и "тех, кто ещё фортранил".

Здравствуйте, Vlad_SP, Вы писали:

V_S>Кхм. А как насчет переиспользования кода?

Разверните мысль?

Здравствуйте, Kolesiki, Вы писали:


K>Потому что вы не поняли суть вопроса: я поставил под сомнение саму идею импорта имён (не затрагивая using-as-alias). Вы можете рационально объяснить катастрофическую необходимость в коде каждого файла(!) писать один и тот же boilerplate только для того, чтобы пользоваться всем классическим дотнетом?

1. У вас студия запрещена что ли Ваш boilerplate уже лет 8 подставляется автоматом, что студией, что решарпером. Ну и чистится автоматом тоже, ставим CodeMaid или любой из аналогов.

2. Это классика проектирования сложных систем: любое новое поведение должно добавляться как opt-in, а не как opt-out.
Другими словами, хочешь что-то заиспользовать — будь любезен объявить это явно. Это позволяет не тестировать все возможные комбинации на предмет конфликтов и не разруливать идиотские ситуации, когда проект перестаёт собираться из-за добавления новой библиотеки в референсы.

И да, раскидыванием по библиотекам эта проблема не решается, классика:

// Assembly A, references ANode
Node Parse(...) { ... }

// Assembly B, references BNode
Node Parse(...) { ... }

// Assembly B, some helper
string SomeHelper(...) { ... }

В проекте везде используются типы из A, используем хелпер из B. Автореференсы засирают лог сборки несколькими тысячами однотипных ошибок, приятной отладки

Для защиты от случайно залетевших дятлов конечно придумали assembly aliases, но это не значит, что надо выбрасывать юзинги и тут же их переизобретать.

K>Про конфликт имён — очевидно и первоклашке, using нужен, но лучше как ключевое слово alias.

3. Юзинги в проекте порождают ещё более забавную проблему с включением в проект чужих исходников. Блин, да даже стандартный сценарий "перетаскиваем файл из проекта в проект" после такого пожелания превращается в минное поле.

Здравствуйте, 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 минут — вот-вот, те самые "кучи г-сходников", которые включают наобум.
Нужна либа? Скомпилял дебаг-версию, подключил, забыл. И конфликтов имён никаких.

K>Откровенно, я ещё не видел такого УЖАСНОГО проекта, где два исходника содержат два "разных" Узла и весь этот кошмар юзается в третьем проекте!
Третий проект может содержать ссылки на сторонние либы первых двух.
И у прокладки возникнет куча головной боли по вписыванию алиасов после добавления второй либы.

Если у Пети проект ссылается на либу Васи, а тот решил добавить ссылку на либу Сергея, то у Пети развалится проект, хотя, ему ни на кой черт не нужен Node из либы Сергея в своем проекте.
Зато ему нужен Node из либы Васи, который почему-то завется VasyaLibNode, а просто потому, что Вася не захотел потом писать везде алиасы. И, не зная что там еще придумает Сергей, Вася все классы так именовать начнет. Тенденция очевидна.

Вы имена переменных в 1С видели?

Да, я понял Вашу идею, и она мне абсолютно не нравится.

Здравствуйте, namespace, Вы писали:

N>Да, я понял Вашу идею, и она мне абсолютно не нравится.

Потому что люди — всегда люди, будут до усрачки защищать свои "первичные знания". Это трудно, я понимаю. И всегда хочется выглядеть умным. Даже умнее, чем можешь себе позволить. И искать пятна на солнце. Ради бога, я никого переубеждать не буду — я уже объяснил с самого начала: я видел ПЯТЬ ПРОЕКТОВ, пять, Карл! В которых в паре исподников нужно было сослаться на неоднозначный класс. Хотите — до конца жизни импортируйте свои классы, я такой обезьяний труд не приемлю. Практика — лучший критерий.

Здравствуйте, namespace, Вы писали:

N>Да, я понял Вашу идею, и она мне абсолютно не нравится.
Не спорьте. Посмотрите остальные посты топикстартера, он с непонятным упорством пытается троллить на темы, в которых явно и очевидно не разбирается.
Ладно бы в КСВ, но в профильных ветках так подставляться — эт уже перебор

Здравствуйте, Kolesiki, Вы писали:

K>За 10 лет шарпенины

С самой школы, что ли, считаешь?