Здравствуйте. Если я сделаю так:

//myExtension.dll -> namespace myExtension
using myComponent;

public class myExtension
{
   public static void Worker(this myComponent myComp, int i)
   {
      ...
   }
}

//myComponent.dll -> namespace myComponent
using myExtension;

public class myComponent
{
   ...
}

//Programm.exe -> namespace Programm
using myComponent;

class myProgramm
{
   public static void Main()
   {
      myComponent comp = new myComponent();
      comp.Woker(5);                             //сработает-ли это ???
   }
}

Смогу-ли я использовать метод расширение Worker, импортировав в Programm только пространство имен myComponent(не импортируя myExtension)

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте. Если я сделаю так:
А>

А>//myExtension.dll -> namespace myExtension
А>using myComponent;

А>public class myExtension
А>{
А>   public static void Worker(this myComponent myComp, int i)
А>   {
А>      ...
А>   }
А>}
А>

А>

А>//myComponent.dll -> namespace myComponent
А>using myExtension;

А>public class myComponent
А>{
А>   ...
А>}
А>

А>

А>//Programm.exe -> namespace Programm
А>using myComponent;

А>class myProgramm
А>{
А>   public static void Main()
А>   {
А>      myComponent comp = new myComponent();
А>      comp.Woker(5);                             //сработает-ли это ???
А>   }
А>}
А>

А>Смогу-ли я использовать метод расширение Worker, импортировав в Programm только пространство имен myComponent(не импортируя myExtension)

Представь себе что вызов comp.Worker(5) заменяться на myExtension.Worker(comp, 5) и ответь на свой вопрос сам

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

B>Представь себе что вызов comp.Worker(5) заменяться на myExtension.Worker(comp, 5) и ответь на свой вопрос сам

Не понял Я не использовал расширения раньше, и не знаю как они себя поведут. А проверить здесь негде...

Здравствуйте, Аноним, Вы писали:

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

B>>Представь себе что вызов comp.Worker(5) заменяться на myExtension.Worker(comp, 5) и ответь на свой вопрос сам

А>Не понял Я не использовал расширения раньше, и не знаю как они себя поведут. А проверить здесь негде...

Я в том смысле, что если-бы это были "обычные" методы, то в Programm не было бы видно myExtension. Распространяется ли это правило на методы расширения — не знаю
Вообще на этот вопрос меня натолкнуло большое количество методов расширений в стандартных классах Framework, где их раньше не было, например String. Как удалось сделать так, что я импортирую только пространство имен в котором объявлен String, а методы расширения всё равно видны в программе

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

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

B>>>Представь себе что вызов comp.Worker(5) заменяться на myExtension.Worker(comp, 5) и ответь на свой вопрос сам

А>>Не понял Я не использовал расширения раньше, и не знаю как они себя поведут. А проверить здесь негде...

А>Я в том смысле, что если-бы это были "обычные" методы, то в Programm не было бы видно myExtension. Распространяется ли это правило на методы расширения — не знаю
А>Вообще на этот вопрос меня натолкнуло большое количество методов расширений в стандартных классах Framework, где их раньше не было, например String. Как удалось сделать так, что я импортирую только пространство имен в котором объявлен String, а методы расширения всё равно видны в программе

Вот смотрите, метод расширения объявляется как обычная статическая функция. Отличается в объявлении только модификатором this. Вообще вызов расширения можно заменить вызовом статической функции. Отсюда и мой совет. Если статическая функция метода расширения будет видна в том месте где вызывается метод, то и метод расширения будет виден.

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

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

B>Вот смотрите, метод расширения объявляется как обычная статическая функция. Отличается в объявлении только модификатором this. Вообще вызов расширения можно заменить вызовом статической функции. Отсюда и мой совет. Если статическая функция метода расширения будет видна в том месте где вызывается метод, то и метод расширения будет виден.

Понятно, короче обычное поведение, как у обычной статической функции. В MSDN написано, что методы расширения "как статические методы", но ни где явно не написано, что они ведут себя так-же. Ведь this в списке параметров, указание компилятору что это метод расширение и вести себя они могут по другому.
Вопрос в общем в другом. Я добрался до VS и провел пару экспериментов, так что этот вопрос отпал. Остался вопрос, как в String сделали так, что кроме обычных методов IntelliSense отображает ещё и методы для него, хотя в нем они не реализуются Я тоже так хочу

Здравствуйте, Аноним, Вы писали:

А>Смогу-ли я использовать метод расширение Worker, импортировав в Programm только пространство имен myComponent(не импортируя myExtension)

Extension methods are defined as static methods but are called by using instance method syntax. Their first parameter specifies which type the method operates on, and the parameter is preceded by the this modifier. Extension methods are only in scope when you explicitly import the namespace into your source code with a using directive.

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

B>Более того классы (на которые кстати тоже есть ограничения) в которых объявляются методы расширения можно делать пабликами, интерналами и пр., т.е. управлять видимостью методов расширения.

Ты уверен по поводу выделенного? Вроде как только public.

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

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

B>>Более того классы (на которые кстати тоже есть ограничения) в которых объявляются методы расширения можно делать пабликами, интерналами и пр., т.е. управлять видимостью методов расширения.

L>Ты уверен по поводу выделенного? Вроде как только public.

По этому поводу в MSDN написано "Класс должен быть видимым для клиентского кода." Interanl можно, Private тоже.

Здравствуйте, Аноним, Вы писали:

L>>Ты уверен по поводу выделенного? Вроде как только public.

А>По этому поводу в MSDN написано "Класс должен быть видимым для клиентского кода." Interanl можно, Private тоже.

Спасибо, не знал.

Здравствуйте, <Аноним>, Вы писали:

> Остался вопрос, как в String сделали так, что кроме обычных методов IntelliSense отображает ещё и методы для него, хотя в нем они не реализуются Я тоже так хочу

Объявляйте метод расширения и все. IntelliSense его будет видеть, есть он виден в этом контексте (т.е. его namespace подключен). Для некоторых методов я сделал следующий трюк: обявил их в глобальном namespace (т.е. без namespace) — в итоге они видны всегда, независимо от подключенных namespace

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

L>Здравствуйте, Аноним, Вы писали:

А>>Смогу-ли я использовать метод расширение Worker, импортировав в Programm только пространство имен myComponent(не импортируя myExtension)

L>

L>Extension methods are defined as static methods but are called by using instance method syntax. Their first parameter specifies which type the method operates on, and the parameter is preceded by the this modifier. Extension methods are only in scope when you explicitly import the namespace into your source code with a using directive.

Это-то понятно. Но как в String сделали, что в списке методов появились методы расширения типа ToArray<T>() Как они их объявляют
Просто я смотрю рефлектором класс String и в упор не вижу объявление метода ToArray<T>(). А IntelliSense в VisualStudio показывает, что есть такой метод расширения Это странно, потому что у класс не может знать о возможном наличии у него метода расширения, т.к. он объявляется в отдельном статическом классе. Я с таким же успехом могу сделать так:

namespace SomeNamespace
{
    static class Extension
    {
        internal static void KissMyAss(this string str)          //это так, для прикола :)))
        {
            Console.WriteLine("Kiss, kiss, please kiss ...");
        }
    }

    public class Programm
    {
        public static void Main()
        {
            string str = "La-la-la...";
            str.KissMyAss();
        }
    }
}

но IntelliSense не покажет, что есть такой метод расширения у класса String

Здравствуйте, Аноним, Вы писали:

А>Это-то понятно. Но как в String сделали, что в списке методов появились методы расширения типа ToArray<T>() Как они их объявляют

string реализует IEnumerable<char>, а в класса Enumerable есть generic-метод ToArray<T>. Его-то студия и показывает.

А>Просто я смотрю рефлектором класс String и в упор не вижу объявление метода ToArray<T>(). А IntelliSense в VisualStudio показывает, что есть такой метод расширения Это странно, потому что у класс не может знать о возможном наличии у него метода расширения, т.к. он объявляется в отдельном статическом классе. Я с таким же успехом могу сделать так:
А>

А>namespace SomeNamespace
А>{
А>}
А>

А>но IntelliSense не покажет, что есть такой метод расширения у класса String

Вообще-то покажет.

Здравствуйте, Аноним, Вы писали:

B>>>Более того классы (на которые кстати тоже есть ограничения) в которых объявляются методы расширения можно делать пабликами, интерналами и пр., т.е. управлять видимостью методов расширения.
L>>Ты уверен по поводу выделенного? Вроде как только public.

А>По этому поводу в MSDN написано "Класс должен быть видимым для клиентского кода." Interanl можно, Private тоже.

Если речь про класс с методом-расширением, то private нельзя, ибо private может быть только вложенный класс, а методы-роасширения во вложенных классах объявлять нельзя. Тоже, кстати сказать, большую свинью подложили Так что только public или internal.

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

L>Вообще-то покажет.

А ну да, показывает Ладно, а почему в MSDN для класса String явно описываются методы расширения? Где для этого класса они определяются? Ведь никаго пространства имен для класса String я не импортирую

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

_FR>Здравствуйте, Аноним, Вы писали:

B>>>>Более того классы (на которые кстати тоже есть ограничения) в которых объявляются методы расширения можно делать пабликами, интерналами и пр., т.е. управлять видимостью методов расширения.
L>>>Ты уверен по поводу выделенного? Вроде как только public.

А>>По этому поводу в MSDN написано "Класс должен быть видимым для клиентского кода." Interanl можно, Private тоже.

_FR>Если речь про класс с методом-расширением, то private нельзя, ибо private может быть только вложенный класс, а методы-роасширения во вложенных классах объявлять нельзя. Тоже, кстати сказать, большую свинью подложили Так что только public или internal.

А почему, тогда так работает:

namespace Programm
{
    static class Extension //кто это если не private ???
    {
        internal static void Print(this string str)
        {
            Console.WriteLine(str);
        }
    }

    public class Programm
    {
        public static void Main()
        {
            string str = "La-la-la...";
            str.Print();
        }
    }
}

Здравствуйте, Аноним, Вы писали:

А>>>По этому поводу в MSDN написано "Класс должен быть видимым для клиентского кода." Interanl можно, Private тоже.

_FR>>Если речь про класс с методом-расширением, то private нельзя, ибо private может быть только вложенный класс, а методы-роасширения во вложенных классах объявлять нельзя. Тоже, кстати сказать, большую свинью подложили Так что только public или internal.

А>А почему, тогда так работает:

А>namespace Programm
А>{
А>    static class Extension //кто это если не private ???
А>    {
А>        internal static void Print(this string str)
А>        {
А>            Console.WriteLine(str);
А>        }
А>    }

А вы посмотрите сами рефлектором. Или почитайте, что ли, документацию. Или попробуйте написать private и скомпилировать и почитайте сообщение компилятора. Всё показывает, что "это" internal.

Кстати, ещё об неизвестных умолчаниях компилятора: автосгенерированный конструктор абстрактного класса:

abstract class X { }

имеет модификатор protected, что более чем разумно.

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

А>>По этому поводу в MSDN написано "Класс должен быть видимым для клиентского кода." Interanl можно, Private тоже.

_FR>Если речь про класс с методом-расширением, то private нельзя, ибо private может быть только вложенный класс, а методы-роасширения во вложенных классах объявлять нельзя. Тоже, кстати сказать, большую свинью подложили Так что только public или internal.

Но при этом private-методы можно использовать как расширения.

Здравствуйте, Аноним, Вы писали:

L>>Вообще-то покажет.

А>А ну да, показывает Ладно, а почему в MSDN для класса String явно описываются методы расширения?

Документация-то рукописная, там что угодно может быть.

А>Где для этого класса они определяются? Ведь никаго пространства имен для класса String я не импортирую

Если ты откроешь документацию по самому методу, то увидишь, где он объявлен.

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

А>>>По этому поводу в MSDN написано "Класс должен быть видимым для клиентского кода." Interanl можно, Private тоже.

_FR>>Если речь про класс с методом-расширением, то private нельзя, ибо private может быть только вложенный класс, а методы-роасширения во вложенных классах объявлять нельзя. Тоже, кстати сказать, большую свинью подложили Так что только public или internal.

L>Но при этом private-методы можно использовать как расширения.

Нет, засада в другом: есть у меня самый обычный класс A в котором используется класс B, да используется так активно, что хотелось бы к этому самому классу B добавить методы-расштрения. Заводит для этой цели отдельный класс не хочется, потому что нигде эти расширения более не нужны, да и использовать эти расширения могут закрытые члены класса A.

Конечно, в данном случае обычный статический метод покрывает за глаза расширение, но вызов расширения всё же выглядит зачастую более удачно.