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