Здравствуйте, _NN_, Вы писали:
_NN>Идея здравая, но как тогда писать обобщённый код для обобщений ?
Сделать свой ассерт
Задача CJ — не покрыть все сценарии любой ценой. Гораздо выгоднее покрыть лучшие из возможных и оставить механизм реализации для остальных.
CodeExceptions — как раз такой механизм.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, _NN_, Вы писали:
_NN>>Идея здравая, но как тогда писать обобщённый код для обобщений ? S>Сделать свой ассерт S>Задача CJ — не покрыть все сценарии любой ценой. Гораздо выгоднее покрыть лучшие из возможных и оставить механизм реализации для остальных. S>CodeExceptions — как раз такой механизм.
Здравствуйте, Sinix, Вы писали:
S>Задача CJ — не покрыть все сценарии любой ценой. Гораздо выгоднее покрыть лучшие из возможных и оставить механизм реализации для остальных.
Я согласен с NN. И потом, лучше иметь единообразный подход, чем разношерстный, а сейчас у нас получается, что для одних случаев можем писать так, а в другом вынуждены городить огород. К тому же без ограничения where T : class код покрывает не лучшие из возможных, а все, и бесплатно
Здравствуйте, rameel, Вы писали:
R>Я согласен с NN. И потом, лучше иметь единообразный подход, чем разношерстный, а сейчас у нас получается, что для одних случаев можем писать так, а в другом вынуждены городить огород. К тому же без ограничения where T : class код покрывает не лучшие из возможных, а все, и бесплатно
И получаем возможность писать badsmell вида
Code.NotNull(2, "Why not?");
Мы пишем инфраструктурный код для 99% пользователей, не для единиц спецов. Поэтому чем проще и однозначнее API, тем лучше.
Здравствуйте, Sinix, Вы писали:
S>И получаем возможность писать badsmell вида S>
S>Code.NotNull(2, "Why not?");
S>
Badsmell писать и сейчас можно
Code.NotNull(new object(), "Why not?");
В плане абусурдности на одной полке. Зато когда надо писать код, упираешься в то, что generic обязан быть классом, либо писать по старинке
Например, расширение dictionary.TryAdd и ему подобные, ключ обязан быть не-null, но написать Code.NotNull мы не можем... Вот и получается, кто в лес, кто по дрова.
S>Мы пишем инфраструктурный код для 99% пользователей, не для единиц спецов. Поэтому чем проще и однозначнее API, тем лучше.
Думается, что человек воспринимающий TKey key == null не запутается и при виде Code.NotNull, скорее наоборот, удивится почему нельзя?
ЗЫ. С другой стороны, у нас в компании все "проаннотиравано", поэтому NotNull-ассертами пользуемся только если ошибка не проявит себя сразу при вызове метода, а вообще ждем C#8 с его nonnullable типами
Здравствуйте, rameel, Вы писали:
R>Например, расширение dictionary.TryAdd и ему подобные, ключ обязан быть не-null, но написать Code.NotNull мы не можем... Вот и получается, кто в лес, кто по дрова.
Ну вот я для таких вещей предпочитаю старый if-throw стиль, т.к. jit его гарантированно оптимайзит даже для древних FW. А вне хелперов "универсальные" проверки и не нужны, как правило.
Если реально нужно — добавим, если нет — нет
R>ЗЫ. С другой стороны, у нас в компании все "проаннотиравано", поэтому NotNull-ассертами пользуемся только если ошибка не проявит себя сразу при вызове метода, а вообще ждем C#8 с его nonnullable типами
+1
Здравствуйте, rameel, Вы писали:
R>ЗЫ. С другой стороны, у нас в компании все "проаннотиравано", поэтому NotNull-ассертами пользуемся только если ошибка не проявит себя сразу при вызове метода, а вообще ждем C#8 с его nonnullable типами
Не у всех ReSharper
К тому же даже с аннотациями может пройти null незамеченным.
Здравствуйте, _NN_, Вы писали:
R>>ЗЫ. С другой стороны, у нас в компании все "проаннотиравано", поэтому NotNull-ассертами пользуемся только если ошибка не проявит себя сразу при вызове метода, а вообще ждем C#8 с его nonnullable типами
_NN>К тому же даже с аннотациями может пройти null незамеченным.
Поэтому NotNull-ассертами пользуемся только если ошибка не проявит себя сразу при вызове метода
Здравствуйте, IT, Вы писали:
IT>А в чём проблема?
Так нельзя
using System;
public class A
{
static void NotNull<T>(T obj)
where T : class
{
}
static void NotNull<T>(T? obj)
where T : struct
{
}
static void F<T>(T t) { NotNull(t); }
public static void Main()
{
}
}
Compilation error (line 16, col 26): The type 'T' must be a reference type in order to use it as parameter 'T' in the generic type or method 'A.NotNull<T>(T)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, _NN_, Вы писали:
IT>>>А в чём проблема? _NN>>Так нельзя
IT>Т.е. с F<T> таких проблем нет?
Если не указывать ограничения на обобщённый тип то нет.
void F<T>(T t) { if(t==null) throw new ArgumentNullException("t"); }
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, _NN_, Вы писали:
_NN>>Пользуясь случаем, вопрос, не стоит ли добавить в CodeJam атрибут ? _NN>>