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

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

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

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

Ну так и я о том же:

using System;

static class Program {
    static void Main() {
        "123".Print();
    }

    private static void Print(this string src) {
        Console.WriteLine(src);
    }
}

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

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

Класс A обычно у меня не static Со static ясное дело никаких проблем.

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

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

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

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

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

Фу, Господи, паранойя меня одолела. Понятно, все методы расширения класса String определяются в System.Linq. Убираешь using System.Linq; и методов расширения как не бывало. Это очень оригинально. Открываешь документацию по классу, а там чудные методы расширения, даже в отдельный раздел вынесены. Вот только непонятно, откуда они взялись и ни где не написано, что увидеть их можно только если некое пространство имен импортируешь. То есть не испытаешь проблем, только если в студии создаешь проект по-умолчанию, тогда ведь using System.Linq; автоматом добавляется. А если будешь писать с нуля, тогда догадывайся сам
Дали-бы как в Википедии редактировать статьи, меньше косяков бы было

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

А>Дали-бы как в Википедии редактировать статьи, меньше косяков бы было

Все гораздо проще — надо просто почитать документацию по языку, которым вы пользуетесь. RTFM, типа.

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

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

А>>Дали-бы как в Википедии редактировать статьи, меньше косяков бы было

L>Все гораздо проще — надо просто почитать документацию по языку, которым вы пользуетесь. RTFM, типа.

При чем тут язык. String класс Framework'a, непосредственно к C# это не имеет отношения, вот я MSDN и читаю.

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

L>>Все гораздо проще — надо просто почитать документацию по языку, которым вы пользуетесь. RTFM, типа.

А>При чем тут язык. String класс Framework'a, непосредственно к C# это не имеет отношения, вот я MSDN и читаю.

Это имеет самое непосредственное отношение к C#.

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

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

L>>>Все гораздо проще — надо просто почитать документацию по языку, которым вы пользуетесь. RTFM, типа.

А>>При чем тут язык. String класс Framework'a, непосредственно к C# это не имеет отношения, вот я MSDN и читаю.

L>Это имеет самое непосредственное отношение к C#.

А ну да, торможу что-то

Здравствуйте, <Аноним>, Вы писали:
А>Фу, Господи, паранойя меня одолела. Понятно, все методы расширения класса String определяются в System.Linq. Убираешь using System.Linq; и методов расширения как не бывало. Это очень оригинально...

Думаю речь про методы класса Enumerable. Он реализует методы Linq для классов реализующих интерфейсы IEnumerable и IEnumerable<T>. А класс string реализует интерфейс IEnumerable<char>.

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

А>Убираешь using System.Linq; и методов расширения как не бывало. Это очень оригинально.

Ну, на то они и расширения. Тем более, как уже писали выше, это расширения не конкретно для класса string, а для всех классов, реализующих интерфейс IEnumerable<T>. Есть подозрение, что попытка поиска всех возможных расширений для текущего контекста — задача очень трудоёмкая (да и неоднозначная).

Кстати, наверное, именно из-за сложности полноценного решения этой задачи разработчики и включили "using System.Linq" в дефолтную заготовку класса — не совсем эстетично, зато "дёшево, надёжно и практично"

Здравствуйте, andy1618, Вы писали:
A>Кстати, наверное, именно из-за сложности полноценного решения этой задачи разработчики и включили "using System.Linq" в дефолтную заготовку класса — не совсем эстетично, зато "дёшево, надёжно и практично"

Еще бы проверяли подлключена ли соответствующая сборка...

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

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

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

_FR>Класс A обычно у меня не static Со static ясное дело никаких проблем.

Да, тут нельзя даже сделать класс с расширениями вложенным.
У методов-расширений какие-то нелепые ограничения на класс, в котором они определяются, интересно, чем они вызваны?