Можно разрешить метод исключительно для перечислений через
https://gist.github.com/MrJul/7da12f5f2d6c69f03d79
public static bool TryParse<TEnum>(string name, out TEnum result)
where TEnum : struct, IComparable, IFormattable, IConvertible
Будет примерно так:
public abstract class EnumClassUtils<TClass> where TClass : class
{
public static TEnum? TryParse<TEnum>(string value) where TEnum : struct, TClass
{
TEnum result;
return Enum.TryParse(name, ignoreCase, out result) ? result : (TEnum?)null;
}
}
public class EnumUtils : EnumClassUtils<Enum>
{
}
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>Согласен.
_NN>>Возможно есть способ обойти, надо думать как.
S>Ну вот нет его. В общем, имеем два варианта:
S>* возможность подсунуть int вместо enum и огрести исключение.
S>* кривой API, который можно использовать вообще не по назначению.
Если сделать абcтрактным
запечатанным с приватным конструктором то максимум, что можно сделать будет это создать экземпляр с нулевым значением.
Не сказал бы, что это серьёзная проблема.
S>Ну а если упарываться поддерживать планку, то надо подрубать Fody:
S>https://github.com/Fody/ExtraConstraints
S>+
S>https://github.com/Fody/Stamp
S>заодно.
Тут конечно без вопросов , что на выходе будет лучше
Здравствуйте, _NN_, Вы писали:
_NN>Можно разрешить метод исключительно для перечислений через https://gist.github.com/MrJul/7da12f5f2d6c69f03d79
Ага, в курсе. Две проблемы:
1. Не сочетается с extension methods.
2. Года четыре назад кто-то из аналайзеров ругался на подобный код, что-то
типа такого выдавал. Кто именно — не вспомню, но точно не решарпер — он переваривает нормально.
Со вторым как бы фиг с ним, воспроизведётся — напишем в саппорт — поправят. С первым что делать?
Лично мне идея держать рядом EnumHelper + EnumExtensions не очень нравится, если остальных устраивает — не вопрос
UPD Вспомнил ещё принципиальный косяк, из-за него и отказался в своё время.
Возможность написать код типа
EnumUtils utils = null;
DoSmth(utils);
Вот что-то не хочу я такие дыры в public api.
UPD2 Объяснение предложенной фичи, если кому-то надо
Здравствуйте, Sinix, Вы писали:
S>Ага, в курсе. Две проблемы:
S>1. Не сочетается с extension methods.
Увы.
S>UPD Вспомнил ещё принципиальный косяк, из-за него и отказался в своё время.
S>Возможность написать код типа
S>S> EnumUtils utils = null;
S> DoSmth(utils);
S>
S>Вот что-то не хочу я такие дыры в public api.
Согласен.
Возможно есть способ обойти, надо думать как.
S>UPD2 Объяснение предложенной фичи, если кому-то надо
Думаю два класса EnumEx и EnumExtensions это не проблема.
Есть ведь TaskEx и ничего
Здравствуйте, _NN_, Вы писали:
_NN>Согласен.
_NN>Возможно есть способ обойти, надо думать как.
Ну вот нет его. В общем, имеем два варианта:
* возможность подсунуть int вместо enum и огрести исключение.
* кривой API, который можно использовать вообще не по назначению.
Ну а если
упарываться поддерживать планку, то надо подрубать Fody:
https://github.com/Fody/ExtraConstraints
+
https://github.com/Fody/Stamp
заодно.
Здравствуйте, _NN_, Вы писали:
_NN>Тут конечно без вопросов , что на выходе будет лучше
Ну вот то же мнение. Я завтра если время будет поиграюсь с fody, по прошлому опыту оно просто работает.
Не сработает — твой вариант, сработает — спрашиваем у AndrewVK, одобрит — закидываю. Нет — снова твой вариант.
В общем у меня есть план и я собираюсь его придерживаться
Здравствуйте, _NN_, Вы писали:
_NN>Тут конечно без вопросов , что на выходе будет лучше
Работает,
обсуждение завёлАвтор: Sinix
Дата: 19.05.16
.