Собственно, несколько лет назад разобрался с ними и хотел было юзать на всю. Но как то тормозило все да, по моему вспечатлению, не получили массового распространения. Вроде бы обещали добавить поддержку на уровне языка, емнип.
Как сейчас? Использовать старые добрые исключения или же переходить на сабж?
Здравствуйте, Shmj, Вы писали:
S>Как сейчас? Использовать старые добрые исключения или же переходить на сабж?
Смотря для чего.
Для большинства проектов для рантайм-проверок проще написать что-то своё. Решение бросать (по умолчанию) неотлавливаемый ContractException очень больно выстреливает по коду. В конечном итоге часть вызовов обкладывается catch{}, что приводит к куда более экзотическим багам, чем если бы контрактов не было бы вообще.
С другой стороны, в code contracts есть куча очень приятных штук для отладки, те же инварианты экономят кучу времени. Но использовать их вместе с самописными проверками (см предыдущий абзац)… это уже перебор.
Ну и наконец самое интересное: статическая верификация. В теории это то, что нужно — экономит время на отладку, совместимо с классическими проверками if-then-throw и в последних версиях почти допилили вывод контрактов, т.е. не нужно копировать их во все перегрузки. На практике всю идею убивает неимоверно долгое время сборки, до нескольких десятков минут. И неимоверная капризность солвера.
Сплошь и рядом проверку приходится переписывать, например, менять ИЛИ на И (с инверсией условий конечно). Или наоборот. Никаких явных закономерностей в этом нет, просто после обновления солвер внезапно начинает находить ложные срабатывания или не срабатывает при явном нарушении контракта. В общем, на поддержку в актуальном состоянии тратится куча лишнего времени. Добавляем сюда никакую активность в оф.репо, никакую поддержку на форуме и явный синдром NIH у авторов. Короче, нужно быть в очень отчаянном положении чтобы всерьёз рассчитывать на пользу от статической верификации в code contracts в текущем виде.
Лет пять назад у меня было побольше оптимизма, но положение за это время не поменялось практически никак. Если у кого есть положительный опыт — было бы очень интересно послушать
Здравствуйте, Shmj, Вы писали:
S>Собственно, несколько лет назад разобрался с ними и хотел было юзать на всю. Но как то тормозило все да, по моему вспечатлению, не получили массового распространения. Вроде бы обещали добавить поддержку на уровне языка, емнип.
S>Как сейчас? Использовать старые добрые исключения или же переходить на сабж?
Исключения это часть контракта. А code contracts это в первую очередь инструмент для описания и контроля за строгим соблюдением.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Исключения это часть контракта. А code contracts это в первую очередь инструмент для описания и контроля за строгим соблюдением.
К сожалению, нет. CC — это попытка натянуть contract-driven подход на неприспособленный к этому рантайм, систему типов и язык. Плюс сделанная очень малыми силами и людьми без опыта энтерпрайз-разработки.
В Code Contracts тонны принципиально неверных решений, которые никогда не сделает человек с опытом поддержки большого по объему кода. По умолчанию бросаются неотлавливаемые исключения, необходимость дублировать контракты в перегрузках и самое обидное — нестабильная работа статической верификации. От версии к версии в нём постоянно что-то ломается, т.е. нельзя просто обновить библиотеку и надеяться на отсутствие ложных срабатываний/не срабатываний.
В общем в теории оно как бы и да, на практике, без очень веских причин — нет.
S>Как сейчас? Использовать старые добрые исключения или же переходить на сабж?
Несколько раз пытался прикрутить CC к проектам от больших до мелких — ни разу не получил ожидаемого эффекта (я от них ожидаю что при правильно написанных контрактах юнит-тесты будут не нужны, только интеграционные). Имхо сама идея 5+, но без поддержки со стороны CLR довести до ума будет нереально.
Nemerle — power of metaprogramming, functional, object-oriented and imperative features in a statically-typed .NET language
Здравствуйте, xednay89, Вы писали:
X>Я всё жду, когда SergeyT. отпишется :)
Он недавно у себя в блоге писал о контрактах. В комментариях дискусс. Он по сути в одиночку сейчас это дело тянет.
Может, за прошедшие пару недель что-то изменилось. Было бы интересно послушать Сергея.
Здравствуйте, Shmj, Вы писали:
S>Собственно, несколько лет назад разобрался с ними и хотел было юзать на всю. Но как то тормозило все да, по моему вспечатлению, не получили массового распространения. Вроде бы обещали добавить поддержку на уровне языка, емнип.
S>Как сейчас? Использовать старые добрые исключения или же переходить на сабж?
Нет. Вместо проверки значения типа в рантайме лучше использовать в параметрах тип в котором недопустимые значения просто невозможны.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Нет. Вместо проверки значения типа в рантайме лучше использовать в параметрах тип в котором недопустимые значения просто невозможны.
Метод принимает float от 0 до 5. Что за тип будет в параметрах.
Другой — от 0 до 20. Тоже что будет?
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Poopy Joe, Вы писали:
PJ>>Нет. Вместо проверки значения типа в рантайме лучше использовать в параметрах тип в котором недопустимые значения просто невозможны.
Doc>Метод принимает float от 0 до 5. Что за тип будет в параметрах. Doc>Другой — от 0 до 20. Тоже что будет?
Будет кривой дизайн. "float от 0 до 5" что-то означает. Допустим размер. Вот и надо передавать тип SizeOfSomething, который сам заботится о своем инварианте. Такой код будет понятнее разработчику, не требует контрактов и прочих костылей и его невозможно сломать неверным вызовом, так как код будет контролироваться компилятором. Если уж язык использует статическую типизацию, то надо пользоваться ее преимуществами.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Будет кривой дизайн. "float от 0 до 5" что-то означает. Допустим размер. Вот и надо передавать тип SizeOfSomething,
Это мы только что ввели SizeOfSomething.NaS (not a size) и PositiveInfinity/NegativeInfinity? И пишем перегрузки операциий и компареров?
PJ>который сам заботится о своем инварианте.
И добавили проверки на null?
PJ>Такой код будет понятнее разработчику,
Это по классу то на дипазон?
PJ> не требует контрактов и прочих костылей и его невозможно сломать неверным вызовом, так как код будет контролироваться компилятором.
Переложили с больной головы на здоровую?
PJ> Если уж язык использует статическую типизацию, то надо пользоваться ее преимуществами.
Здравствуйте, _Raz_, Вы писали:
_R_>Это мы только что ввели SizeOfSomething.NaS (not a size) и PositiveInfinity/NegativeInfinity? И пишем перегрузки операциий и компареров?
Эээ... зачем бы? SizeOfSomething может содержать только значения от 0 до 5, ни при каких других условиях он не создастся.
Перегрузки операторов конечно надо. Потому что, если размер в метрах, то и складывать его можно только с размером в метрах, а не любым случайным float. Так же как и размер 1 метр и в 1000мм равны, не смотря на разные значения float.
_R_>И добавили проверки на null?
float value тип, таким же можно сделать и SizeOfSomething, либо использовать Optional<SizeOfSomething>. Вот чего точно не стоит делать, так передавать null.
_R_>Это по классу то на дипазон?
По классу на сущность. Если разработчик строит дизайн на диапазонах float, то тут случай серьезнее.
_R_>Переложили с больной головы на здоровую?
На компилятор. Надеюсь у него здоровая голова и самое главное железная.
_R_>Там где они действительно преимущества.
Это то самое место.
Здравствуйте, Shmj, Вы писали:
S>Собственно, несколько лет назад разобрался с ними и хотел было юзать на всю. Но как то тормозило все да, по моему вспечатлению, не получили массового распространения. Вроде бы обещали добавить поддержку на уровне языка, емнип.
S>Как сейчас? Использовать старые добрые исключения или же переходить на сабж?
Правда попробовал вначале сюда залить все полотно, но что-то больно сложно было редактировать.
Поэтому полноценный ответ здесь: Начать ли использовать контракты?.
Здравствуйте, Poopy Joe, Вы писали:
PJ> "float от 0 до 5" что-то означает. Допустим размер. Вот и надо передавать тип SizeOfSomething, который сам заботится о своем инварианте.
Т.е. называем каждый используемый вид значений своим типом? В результате получаем кучу дополнительного кода приведения одного к другому, сравнений, присвоений и т.д. Идея в принципе не лишена смысла, но реализация ее в стиле "новый тип на каждый чих" это будет страшно.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Poopy Joe, Вы писали:
PJ>> "float от 0 до 5" что-то означает. Допустим размер. Вот и надо передавать тип SizeOfSomething, который сам заботится о своем инварианте.
Doc>Т.е. называем каждый используемый вид значений своим типом? В результате получаем кучу дополнительного кода приведения одного к другому, сравнений, присвоений и т.д. Идея в принципе не лишена смысла, но реализация ее в стиле "новый тип на каждый чих" это будет страшно.
А if на каждый чих это не страшно? А контракты на каждый чих не то же самое? Тот же самый код но в разных местах и в большем количестве.
Вместо того, чтобы компилятор проверял и гарантировал корректность использования типа лучше оставить это в кривых руках разработчика?
Здравствуйте, Poopy Joe, Вы писали:
PJ>А if на каждый чих это не страшно? А контракты на каждый чих не то же самое?
Нет, не тоже самое. В случае контрактов
*) Не надо писать код для SizeOfSomething + SizeOfSomething, SizeOfSomething + SizeOfSomething2 итд
*) Приведение SizeOfSomething к другим "физическим" типам
*) If для проверки вам не удастся привязать к интерфейсам (будут или вызовы вручную класса проверки или копипаста в каждую реализацию)
*) Не всегда диапазон зависит от физической величины. Метод может вполне иметь свои ограничения.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Poopy Joe, Вы писали:
PJ>>А if на каждый чих это не страшно? А контракты на каждый чих не то же самое?
Doc>Нет, не тоже самое. В случае контрактов Doc>*) Не надо писать код для SizeOfSomething + SizeOfSomething, SizeOfSomething + SizeOfSomething2 итд
Надо! Или нет гарантии, что радианы не будут складываться с градусами, а размер головы с размером ноги.
Doc>*) Приведение SizeOfSomething к другим "физическим" типам
Что значит приведение? Другая величина это другая величина. Типа каста к float? Так весь смысл в том, чтобы этого не требовалось.
Doc>*) If для проверки вам не удастся привязать к интерфейсам (будут или вызовы вручную класса проверки или копипаста в каждую реализацию)
Не понял. Какой if, какой проверки? Интерфейс с типом SizeOfSomething не требует дополнительных проверок.
Doc>*) Не всегда диапазон зависит от физической величины. Метод может вполне иметь свои ограничения.
И? Допустим метод принимает возраст и требует, чтобы он был больше 18 лет. Тогда параметр будет например Adult<Age>. Вызываемый метод гарантированно имеет правильные значения, а вызывающие метод просто физически не сможет послать неверные данные, об этом заботится компилятор. А чем тут помогут контракты? Выкинут исключения во времени исполнения? Очень "полезно".
Здравствуйте, Poopy Joe, Вы писали:
PJ>И? Допустим метод принимает возраст и требует, чтобы он был больше 18 лет. Тогда параметр будет например Adult<Age>. Вызываемый метод гарантированно имеет правильные значения, а вызывающие метод просто физически не сможет послать неверные данные, об этом заботится компилятор. А чем тут помогут контракты? Выкинут исключения во времени исполнения? Очень "полезно".
Дык, Adult<Age> где-то будет из обычного Age получаться? В итоге всё равно без рантайм проверок не обойтись.
Здравствуйте, Poopy Joe, Вы писали:
PJ>Надо! Или нет гарантии, что радианы не будут складываться с градусами, а размер головы с размером ноги.
Вот как раз в вашем варианте это и надо. Например: HumanHeight = HeadHeigh + BodyHeight + LegHeight
В варианте с контрактами это будут три поля int или float и просто будет сумма. А гарантии будут в тестах.
Да, эти тесы и у вас будут, но к ним еще бонусом тесты приведения типов для сложения.
PJ>Что значит приведение? Другая величина это другая величина.
А как еще сложить HeadHeigh и BodyHeight?
Doc>>*) Не всегда диапазон зависит от физической величины. Метод может вполне иметь свои ограничения. PJ>И? Допустим метод принимает возраст и требует, чтобы он был больше 18 лет. Тогда параметр будет например Adult<Age>.
*) у вас класс Adult должен знать о Age, уметь извлекать из него значения. Лишний класс, лишние тесты, да еще и с жесткой связью.
*) Если у вас будут методы для "до 16", "до 18" и для всех. Будете еще классы создавать на каждый чих?
PJ>А чем тут помогут контракты?
Contract.Requires(18 < age);
PJ>Выкинут исключения во времени исполнения? Очень "полезно".
А что сделает Adult<Age> если Age будет больше 18?
Кстати, исключение тут вполне уместно, т.к. скорее всего это означает что у вас как-то или малолетка "пролез" через авторизацию, или где-то ошибка в логике загрузки юзеров. Ведь для метода, например, логина такой контракт не уместен (получится что вы хотите BL в контракты зашить)
