- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
public class Switch
{
public Switch(object switchElement)
{
Object = switchElement;
}
public object Object{get; private set; }
}
public static class SwitchExtensions
{
public static Switch Case<T>(this Switch switchCase, Func<T, bool> isTrue, Action<T> action) where T : class
{
return Case(switchCase, isTrue, action, false);
}
public static Switch Case<T>(this Switch switchCase, Func<T, bool> isTrue, Action<T> action, bool fallThrough) where T : class
{
if (switchCase == null)
return null;
var obj = switchCase.Object as T;
if (obj != null)
if (isTrue(obj))
{
action(obj);
return fallThrough ? switchCase : null;
}
return switchCase;
}
}
//пример использования
IImporter<AccountModel> result = null;
new Switch(type)
.Case<string>(x => x == ".xls", y => result = new ExcelImporter())
.Case<string>(x => x == ".csv", y => result = new CsvImporter());
return result;
У нас будет свой Switch/Case с преферансом, куртизанками и экстеншен методами
Follow us!
- да, за место обычного switch он пройдется по порядку по всем case
- да, при визуальном виде записи case кажется что action выполнится в любом случае, но ведь реалиция есть и можно посмотреть
Получается что говнистоть будет только в том случае, если у автора там всегда string, но метод - универсален
Мне даже стало инетерсно и я нагуглил его на stackoverflow
http://stackoverflow.com/a/1426626
> красоту extension-ов
Я знаю. Просто многие программисты их юзают когда надо и когда не надо..
> Минус не я вам поставил
Это стертор ;)
Но все же интересно услышать, чем подход из топика лучше пачки ифов. Ведь семантика тут именно от пачки ифов (ну или от case when из sql, но там нет fallthrough), а не от свича.
Но я себе не очень преставляю адекватную читаемость if-а, который дублирует логику например where T : class, некрасиво будет, много кода, т.е. это есть огранчение .Case<int>(x => x == 5, y => result = new CsvImporter()); А если посложнее, то совсем каша будет. Все таки так более наглядно, удобно, красиво
;D
Не совсем понял. Можно пример мли другими словами?...
Просто я совсем не вижу разницы между кейс из топика и обычным ифом. То же условие в первом аргументе. То же действие во втором. Тот же fallthrough который эквивалентен наличию/отсутствию else. Какого-то нового функционала тут не добавили. Или я просто чего-то не замечаю? ;)
Ифы это тоже треш конечно же, но они хотя бы понятнее.
Если их не много, например два, то вполне себе вариант.
Но я бы делал какой-никакой классификатор все же.
Например, если на будущее форматы могут меняться, то последние строчки придется менять всегда.
я тоже что-то похожее когда-то делал
P.S. Хотя я нашел плюс у этой записи - в разных ветках кейса можно писать разные типы. С ифами пришлось бы вставлять проверку и каст.
Он просто не скомпилируется, в отличает от 1-го примера. Нужна ещё проверочка, а потом ещё проверочка :) И что выйдет красивее ещё спорный вопрос
И это хорошо ;)
По идее мап: ключ-действие решает трабл в одну строчку, но нет, апологеты тру красивого программирования суют свои лямбды везде где ни попадя.
И да, старые добрые ифы тут куда лучше смотрятся.
зачем есть же Dictionary<string,delegate>.
В сишном switch/case действие тоже выбирается по ключу, но исполняется одно или несколько действий (в зависимости от break'ов).
В коде автора, case when в sql и пачке if/else последовательно проверяются условия (которые могут быть не только == "foo", но и любым другим предикатом) до тех пор, пока одно из них не вернет true.Тогда выполняется одно действие (в коде автора может и несколько, если fallthrough = true).
Ну неужели не чувствуете разницу в семантике? :)
Но все равно цель остальных конструкций, это либо выбрать одно действие, либо выполнить первое попавшееся действие, то бишь одно единственное .
ЖЖошь, сотона! )
)
А я стихи пишу, вот, послушай:
Я помню чудное мгновенье:
Передо мной явилась ты,
Как мимолетное виденье,
Как гений чистой красоты.
http://lurkmore.to/%D0%91%D0%BB%D1%8D%D0%BA%D0%B4%D0%B6%D0% B5%D0%BA_%D0%B8_%D1%88%D0%BB%D1%8E%D1%85 %D0%B8
А ссылку погубил злой рок.
Вот новая.
http://images.t-nation.com/forum_images/a/5/a5d6f_ORIG-tumblr_lh8ojoMhBJ1qbylvso1_500.jpg
)
Там пробелы убрать, которые ГК доставил, и всё ок.
Продублирую:
http://lurkmore.to/Блэкджек_и_шлюхи
Более простое решение этой проблемы
И чтоб все эти полезности можно было по одной включать-выключать.
:O
Это всё легко реализуется. Главная сложность - запилить нормальный интерфейс настроек со 100500 галочками + расширяемость (чтоб каждый мог свою опцию добавить, но при этом всё оставалось чем-то относительно целым и не скатилось в говно довольно быстро).
Ну и минусование гоатсе - в общем случае эквивалентно капче.
Остальное же - найти элемент или массив элементов и сделать "map <опция> <элементы>". Vindicar сделал основу, vistefan, если не ошибаюсь в никах, сделал выделение олдфагов.
ГОСТ Р42.100500 ГОАТСЕ
Но в крайнем случае - вручную жать на кнопку "скрыть" и хранить, скажем, в localStorage факт сокрытия. Или, как уже раньше предлагали (и делали), игнорить определённых юзеров.
В основном тут возникают всплески школоты, которая не особо меняет формат гоатсе и сообщений о поиске кавказцев. А взрослых тонких троллей крайне мало - их и вручную можно скрыть или почитать их комментарии для самообразования.
свиток смотрит оценку за пост, выставленную другими участниками, и на основе этого выставляет аналогичную: к примеру, если стоит минус, свиток декрементит, если плюс - инкрементит. Лажа в том, что свиток заранее не знает, кто выставлял оценку. Это может быть например Борманд, а может быть и залетный тролль, которому понравилось гоатсе. Бараны вышли из положения так. Свиток проверяет, есть ли минусы, если есть, то сколько? Если много - минусует. Бараны, такие бараны.
Я знаю, о чем говорю, я проверял:
как-то раз мило пошутил (мило, но не остроумно, это было сделано намерено) в топике у ProgramistOtBaga. Кто-то плюсанул. Потом пошло-поехало, плюсовать. А шутка была скорее глупая, ее минуснуть надо было. Правда, кое-кто и минусовал, чувствуя подвох - они подтирали мне результат теста (поэтому я и решил, что свиток есть у 3-4 человек)
Возможно, что свитка и вовсе нет - тогда вывод еще хуже: стадное чувство детектед; ее разобравшись в сути поста жать + или -, только потому, что другие оценили - как то уныло. Ну да баг им судья.
>>обслужу
>>кавказец
>>хуястые
>>минет
>>подставлю
>>пидор
>>сосет
и т.п. в этом роде, ибо настоебало читать непотребности, которые регулярно сеет чей-то приголубленный мозг.
Уважаю.
Почитал я комментарии к постам праграмиста. Царит рандом, который народ сам устроил. Одни выступают против кормления троллей и топят все комменты, другие продолжают плюсовать годные комментарии (в основном - позитивные. нейтральные комментарии обычно утопают), третьи хотят минуснуть, как и первые, но им пофиг на содержание комментария - и они ставят то, что все ставят.
Особенно порадовал разброс для моего комментария с советом зарегистрировать десяток ботов. Первая группа минуснула, вторая поняла юмор и плюсанула, третья ставила рандомно.
Сам плюсанул понравившиеся комментарии про драйвер на html, когда у него ещё не было столько плюсов, и про 12 стульев. Вторая и третья группы со мной согласились, комментарии в плюсе.
По-моему, наличие свитков надо проверять не по постам троллей.
Мой неплохо справляется.
> когда писал анти-спам для нашего сайта потому, что какой-то урод спамит форум
> рекламируя алмазные буры, бумажные пакеты, резиновые фаллосы, средства для потенции и прочую гадость
Известный борец со спамом, Доктор Смегма.
... тырил пароли и сливал их на багминот