public static int? ToDouble([CanBeNull] this string str ...)
2. Extension-методы к базовым типам надо перенести в namespace CodeJam.Extensions или что-то типа того. В крупных проектах библиотеку с таким "подарком" просто не дадут подрубить.
Здравствуйте, Sinix, Вы писали:
S>2. Extension-методы к базовым типам надо перенести в namespace CodeJam.Extensions или что-то типа того. В крупных проектах библиотеку с таким "подарком" просто не дадут подрубить.
ИМХО неймспейса CodeJam вполне достаточно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
S>>2. Extension-методы к базовым типам надо перенести в namespace CodeJam.Extensions или что-то типа того. В крупных проектах библиотеку с таким "подарком" просто не дадут подрубить. AVK>ИМХО неймспейса CodeJam вполне достаточно.
Неа. Это типичная ошибка проектировщика — закладываться на "так сделаю только я".
Я узнал, что так делать нельзя, сложным способом: уже разошедшаяся сборка подкладывала свинью разработчикам при переезде на 4й фреймворк. Проблема была в нескольких методах-расширениях, что-то типа .Zip() и Stopwatch.Restart(), но могу и наврать.
Просто убрать юзинг от моей библиотеки тоже не вариант был — тогда отпадали другие полезные фишки.
Здравствуйте, Sinix, Вы писали:
AVK>>ИМХО неймспейса CodeJam вполне достаточно. S>Неа. Это типичная ошибка проектировщика — закладываться на "так сделаю только я".
Никто на это не закладывается. У нас уже есть неймспейс CodeJam и его надо указать явно. От того что вместо CodeJam надо будет написать CodeJam.Extensions конфликтов сильно не убавится. Ну и на крайний случай есть using static.
S>Просто убрать юзинг от моей библиотеки тоже не вариант был — тогда отпадали другие полезные фишки.
А просто явно прописать неймспейс при вызове? У меня таких ситуаций бывало — но все сравнительно легко разруливалось одним нажатием решарперовского хоткея.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
S>>Просто убрать юзинг от моей библиотеки тоже не вариант был — тогда отпадали другие полезные фишки.
AVK>А просто явно прописать неймспейс при вызове? У меня таких ситуаций бывало — но все сравнительно легко разруливалось одним нажатием решарперовского хоткея.
Ну да, само по себе это не проблема.
Затык был в том, что проблемы были не у меня, а у сторонних разработчиков. И как оказалось, оно было массово — я сорвал джек-пот
Мораль истории: любые расширения на популярные типы должны быть opt-in.
One simple way to improve the robustness of your extension method library is to put extension methods into their own namespace. This is the strategy employed by the 3.5 version of the .NET Framework. By putting extension methods into their own namespace you enable consumers to include or exclude them separately from the rest of your library. This makes them pluggable, allowing users to easily replace extension method implementations with other implementations if they wish (which is at the heart of the LINQ provider model). This in turn then makes it easier for them to resolve any conflicts that may arise (see part 2 for information about extension method precedence levels).
4. Think twice before extending types you don’t own
If you only write extension methods for types you own, then you never have to worry about your extensions being broken by changes to the type being extended. On the other hand, if you are extending other peoples types than you are essentially at their mercy. Alternatively, you can minimize this risk by choosing names that are unlikely to be used by someone else, or by minimizing the total number of extension methods you define (i.e reducing surface area). One technique for doing this may be to write one extension method that converts the underlying object to a different type that is controlled by you.
...
7. Please ignore this advice where it is not appropriate
I mentioned this at the beginning of the post, but I thought it was worth pointing out again: for most programs you should ignore this advice. Adding extension methods to any type is a great way to improve productivity and simplify code. You should do this wherever it feels beneficial to you, without worrying about any of these details. However, if you need to write an API that can be consumed by a lot of programmers (say thousands or even millions), then I think it’s worthwhile for you to consider these constraints in your designs
Здравствуйте, Sinix, Вы писали:
S>Мораль истории: любые расширения на популярные типы должны быть opt-in.
Они и так opt-in. Оно ж не в System расположено, а в CodeJam.
S>One simple way to improve the robustness of your extension method library is to put extension methods into their own namespace.
При этом МС ни в фреймворке, ни в дополнительных библиотеках такого не делает.
S> This is the strategy employed by the 3.5 version of the .NET Framework.
Это где там такое? System.Linq.Enumerable и System.Linq.Queryable вижу. System.Xml.Linq.Extensions тоже вижу. А вот чтобы экстеншены были в отдельном неймспейсе — не вижу.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
S>>Мораль истории: любые расширения на популярные типы должны быть opt-in. AVK>Они и так opt-in. Оно ж не в System расположено, а в CodeJam.
Оно чересчур opt-in
Подключаем, скажем, ассерты — получаем "Hello".ToDouble() в нагрузку
S>>One simple way to improve the robustness of your extension method library is to put extension methods into their own namespace. AVK>При этом МС ни в фреймворке, ни в дополнительных библиотеках такого не делает.
Ну дык куча *.Linq-неймспейсов на что?
Кроме них расширения активно используются разве что для Reflection, и то потому что там API менять после развлекухи с TypeInfo — уже совсем перебор было.
Здравствуйте, AndrewVK, Вы писали:
S>>Ну дык куча *.Linq-неймспейсов на что? AVK>Там много чего еще помимо расширений имеется.
Ну вот тем не менее оно позволяет не подрубать Linq, когда оно не требуется.
Я ж не настаиваю на конкретном namespace, главное чтоб оно не в корне было.
Здравствуйте, AndrewVK, Вы писали:
AVK>Убрал все string related функции в отдельный неймспейс.
Ура, спасибо!
AVK>Вообще такие вещи надо сразу было говорить, чтобы не ломать совместимость.
Да ладно, это ж ещё 0.x версии. По semver API стабилизируется только после релиза 1.0. Всё ок т.е.
