Здравствуйте, Mamut, Вы писали:
M>Можно это увидеть на полноценном примере? Там всего-то несколько усложнений по сравнению с реальностью 
Да просто добавляешь свои обычные рантайм проверки в функции Decrease и Increase. Ничего касающегося статической типизации там больше не видно. К сожалению. ))) Потому как чем больше можно перевести в статику, тем лучше.
M>Да нет. Все ту же 
Я просто говорю, что твой пример показывает, что с точки зрения программиста все стало сложнее. Где мы проверяем условия статически? А где — в рантайме? Не маскирует ли стат. типизация необходимую проверку в рантайме? В нужном ли месте я поставил стат. типизацию, и правильно ли, что во втором твоем примере происходит рантайм проверка? С ростом количества условий это превратится в непонятный никому звиздец, имхо.
Я тебе уже в который раз говорю, что сложность не увеличится (более моего первого примера). Другое дело, что для твоей задачки польза от всего этого не особо есть и смысл играться с таким есть только ради демонстрации принципа на форуме. Но это в твоей задачке, а есть же много других. )))
M>А как только для разруливания и проверки этого звиздеца мы вставляем тесты, как ценность стат. проверок начинает падать экспоненциально.
Ну у тестов имеются горы своих специфических проблем... )
_>>Максимум, что могут наши современные средства, это свести введение правил до действительно одной точки, с автоматическим расползанием их по всему коду. И как раз в таком статическая типизация очень помогает.
M>Не понял этой фразы и утверждения
Если у нас есть какие-то ограничения на бизнес-логику (например как в твоей задачке — "отправленное нельзя увеличивать"), то очевидно лучше чтобы сам код проверки был написан ровно в одной точке программы, вызываясь из всех нужных мест. Статическая типизация отлично подходит для таких стратегий. Более того, она может ещё проконтролировать, чтобы не было мест без вызова проверки. Хотя это естественно не единственный способ реализации.
_>>Ну в исполняемый файл в итоге попадает или один или ноль if'ов. А в исходнике да, разрастаемся... )))
M>Ну, вообще-то по большому счету глубоко наплевать на то, что попадает в исполняемый файл. Время программиста, который будет все это писать и разбирать потом, важнее намного.
В твоей задаче — конечно. А в других вполне бывает что всё наоборот.
M>Так. Я про это и говорю: данные приходят строго из рантайма. Про «функции перевода состояния» я слышу уже скоро месяц, как, но никто так и не осилил описать эти «функции состояния» до уровня полноценного примера
Ну вот прямо в моём примере видны эти функции. Например функция SendOrder переводит из состояния Unknown (ну и не заданного мною Increase&Decrease) в состояние OnlyDecrease.
M>И вообще. Что значит «функции состояния»? У нас нет никаких «функций перехода состояния». Изменение суммы заказа может происходить через неделю после того, как заказ создан. При чем тут «функции состояния»? Перед тем, как изменить сумму заказа, заказ будет загружен из базы данных в любом из четырех (из примера) или полутора десятков (в реальности) состояний.
И? ) Не пойму с чем ты споришь то? ) Я разве утверждал, что весь твой пример можно покрыть статикой? ) Естественно там останется куча рантайм проверок. Я просто поясняю, что статические тоже будут встречаться и не так редко, как ты думаешь. Но всё же наверное недостаточно часто, чтобы делать подобное в твоём случая. А вот в других задачах, где процент повыше, это уже явно имеет смысл.
Однако тут то у нас форум и вопрос стоял (как я понял) не в несообразности применения данной технологии к конкретной задаче, а в демонстрации самой возможности подобного и механизма действия. С этим вроде как мой пример полностью справляется.
