Пожалуйста, объясните четко и понятно раз и навсегда. Как избегают конфликтов имен при использовании extension methods, а особенно при засовывании их в стандартные интерфейсы .NF?

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

RO>Пожалуйста, объясните четко и понятно раз и навсегда. Как избегают конфликтов имен при использовании extension methods, а особенно при засовывании их в стандартные интерфейсы .NF?

Конфликтов с кем?

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

RO>Пожалуйста, объясните четко и понятно раз и навсегда. Как избегают конфликтов имен при использовании extension methods, а особенно при засовывании их в стандартные интерфейсы .NF?

1) Задавая им разные сигнатуры
2) Размещая из в разных пространствах имен
3) Всегда остается возможность вызывать extension method просто как статический метод, явно указав класс, где он определен

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

RO>>Пожалуйста, объясните четко и понятно раз и навсегда. Как избегают конфликтов имен при использовании extension methods, а особенно при засовывании их в стандартные интерфейсы .NF?

L>Конфликтов с кем?

Один юзер создал, например, My.Email ToEmail(this String s). А другой — Other.Email ToEmail(this String s). Оба хотят, чтобы "billg@microsoft.com".ToEmail() превращалось в их любимый класс почтовых адресов. Но поскольку поддержки пространств имен в extension methods не наблюдается, возникает явный конфликт, потому что неясно, какой ToEmail выбрать. Как избегают таких конфликтов?

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

RO>Но поскольку поддержки пространств имен в extension methods не наблюдается, возникает явный конфликт, потому что неясно, какой ToEmail выбрать.

Как же не наблюдается? Ты в спецификацию языка заглядывал по этому вопросу?

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

L>>Конфликтов с кем?

RO>Один юзер создал, например, My.Email ToEmail(this String s). А другой — Other.Email ToEmail(this String s). Оба хотят, чтобы "billg@microsoft.com".ToEmail() превращалось в их любимый класс почтовых адресов. Но поскольку поддержки пространств имен в extension methods не наблюдается, возникает явный конфликт, потому что неясно, какой ToEmail выбрать. Как избегают таких конфликтов?

А что ты имеешь в виду под поддержкой пространств имен? extension методы будут искаться только в импортированных пространствах имен.

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

RO>>Пожалуйста, объясните четко и понятно раз и навсегда. Как избегают конфликтов имен при использовании extension methods, а особенно при засовывании их в стандартные интерфейсы .NF?

N>2) Размещая из в разных пространствах имен
А как потом указывать пространства имен при вызове extension methods?

N>3) Всегда остается возможность вызывать extension method просто как статический метод, явно указав класс, где он определен
Так представь себе: юзер написал метод Days(this Integer i) с тем, чтобы писать Date TenDaysAgo = 10.Days().Ago(). Это распространилось. А потом к проекту подключили библиотеку, которая определила метод с тем же именем, и полпроекта теперь не компилируется. И теперь переписывать все упоминания этого extension method?

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

RO>>Но поскольку поддержки пространств имен в extension methods не наблюдается, возникает явный конфликт, потому что неясно, какой ToEmail выбрать.

N>Как же не наблюдается? Ты в спецификацию языка заглядывал по этому вопросу?

Их там можно указать явно? SomeObject.MyNamespace.MyExtensionMethod().

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

RO>Так представь себе: юзер написал метод Days(this Integer i) с тем, чтобы писать Date TenDaysAgo = 10.Days().Ago(). Это распространилось. А потом к проекту подключили библиотеку, которая определила метод с тем же именем, и полпроекта теперь не компилируется. И теперь переписывать все упоминания этого extension method?

Если ненароком extension method во второй библиотеке находится в том же пространстве имен, что и в первой, то придется переписывать. Если в другом пространстве имен, то конфликт может возникнуть только в тех файлах, где импортированы через директивы using оба пространства имен.

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

N>>Как же не наблюдается? Ты в спецификацию языка заглядывал по этому вопросу?

RO>Их там можно указать явно? SomeObject.MyNamespace.MyExtensionMethod().

Нет, не так. Либо через директивы using, либо вызывая метод, как статический.

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

RO>>Так представь себе: юзер написал метод Days(this Integer i) с тем, чтобы писать Date TenDaysAgo = 10.Days().Ago(). Это распространилось. А потом к проекту подключили библиотеку, которая определила метод с тем же именем, и полпроекта теперь не компилируется. И теперь переписывать все упоминания этого extension method?

N>Если ненароком extension method во второй библиотеке находится в том же пространстве имен, что и в первой, то придется переписывать. Если в другом пространстве имен, то конфликт может возникнуть только в тех файлах, где импортированы через директивы using оба пространства имен.

Понятно.

Тот, кто злоупотребляет using-директивами, ССЗБ в любом случае.

(Это мы тут флеймим в соседнем форуме, хотелось достоверно выяснить.)

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

RO>Тот, кто злоупотребляет using-директивами, ССЗБ в любом случае.

Надо иметь в виду, что иногда конфликта можно избежать за счет того, что классы в пространстве имен, импортированные с помощью директив using во внутренней декларации, скрывают классы в пространстве имен, импортированные с помощью директив using во внешней декларации. Примерно так:

namespace MyApplication
{
    using A;
    namespace Startup
    {
        using B;
        class Program
        {
            static void Main()
            {
                "".Foo(); // Вызывается B.Stuff.Foo несмотря на using A
            }
        }
    }

    namespace A
    {
        static class Stuff
        {
            public static void Foo(this string x) { }
        }
    }

    namespace B
    {
        static class Stuff
        {
            public static void Foo(this string x) { }
        }
    }
}

Подозреваю, что конфликт одинаковых пространств имен из разных сборок можно разрешить с помощью extern aliases.

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

N>Подозреваю, что конфликт одинаковых пространств имен из разных сборок можно разрешить с помощью extern aliases.

Так же в природе встречаются методы-расширения (если их можно так назвать) с одинаковой сигнатурой и объявленные в одной сборке в одном пространстве имён, но в разных классах

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

_FR>Так же в природе встречаются методы-расширения (если их можно так назвать) с одинаковой сигнатурой и объявленные в одной сборке в одном пространстве имён, но в разных классах

Вообще не представляю, как их можно использовать в качестве расширений
Разве что если один не public, то можно организовать доступ к другому.

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

_FR>>Так же в природе встречаются методы-расширения (если их можно так назвать) с одинаковой сигнатурой и объявленные в одной сборке в одном пространстве имён, но в разных классах

N>Вообще не представляю, как их можно использовать в качестве расширений
N>Разве что если один не public, то можно организовать доступ к другому.

Так почему бы компилятору не предупредить об этом?
При вызове — ясное дело, будет ошибка. Но вот если расширения, как уже предлагается, таки будет дозволено делать в "обычных" (не только статик "верхнего" уровня) классах, то создаваться расширений будет большое множество (сейчас, диву даюсь: кое-кто не делает иногда расширения [да и я в том числе] именно потому, что для них лениво отдельный класс заводить — часто требуется один-два-три метода разширения). И в "больших" сборках объёмных пространств имён (a-la System.Windows.Forms) могут возникать конфликтики.