M>>Можно это увидеть на полноценном примере? Там всего-то несколько усложнений по сравнению с реальностью

_>Да просто добавляешь свои обычные рантайм проверки в функции Decrease и Increase.


Если это так просто, можно наконец увидеть законченный пример?

_>Ничего касающегося статической типизации там больше не видно. К сожалению. ))) Потому как чем больше можно перевести в статику, тем лучше.

Ну так переводи

_>Я тебе уже в который раз говорю, что сложность не увеличится (более моего первого примера). Другое дело, что для твоей задачки польза от всего этого не особо есть и смысл играться с таким есть только ради демонстрации принципа на форуме. Но это в твоей задачке, а есть же много других. )))

Приводи другие задачи

_>>>Максимум, что могут наши современные средства, это свести введение правил до действительно одной точки, с автоматическим расползанием их по всему коду. И как раз в таком статическая типизация очень помогает.
M>>Не понял этой фразы и утверждения

_>Если у нас есть какие-то ограничения на бизнес-логику (например как в твоей задачке — "отправленное нельзя увеличивать"), то очевидно лучше чтобы сам код проверки был написан ровно в одной точке программы, вызываясь из всех нужных мест. Статическая типизация отлично подходит для таких стратегий. Более того, она может ещё проконтролировать, чтобы не было мест без вызова проверки. Хотя это естественно не единственный способ реализации.


Ахахахахахахахахаха Вы уже договоритесь между собой, подходит или не подходит. Тут рядом Evgeny.Panasyuk утверждал, что в моем случае стат. типизация бессмысленна именно потому что все проверки были перенесены в одну функцию

_>>>Ну в исполняемый файл в итоге попадает или один или ноль if'ов. А в исходнике да, разрастаемся... )))
M>>Ну, вообще-то по большому счету глубоко наплевать на то, что попадает в исполняемый файл. Время программиста, который будет все это писать и разбирать потом, важнее намного.

_>В твоей задаче — конечно. А в других вполне бывает что всё наоборот.

В подавляющем большинстве задач именно так.


M>>Так. Я про это и говорю: данные приходят строго из рантайма. Про «функции перевода состояния» я слышу уже скоро месяц, как, но никто так и не осилил описать эти «функции состояния» до уровня полноценного примера

_>Ну вот прямо в моём примере видны эти функции. Например функция SendOrder переводит из состояния Unknown (ну и не заданного мною Increase&Decrease) в состояние OnlyDecrease.

Это они видны в твоем примере, потому что тебе так удобно. На практике SendOrder запишет в заказе поле is_sent=true и запишет в базу. Изменение суммы заказа, повторю, может произойти через неделю после того, как заказ отправился. И никаким переведением в «OnlyDecrease» SendOrder не будет заниматься, потому что это не ее область ответственности.

M>>И вообще. Что значит «функции состояния»? У нас нет никаких «функций перехода состояния». Изменение суммы заказа может происходить через неделю после того, как заказ создан. При чем тут «функции состояния»? Перед тем, как изменить сумму заказа, заказ будет загружен из базы данных в любом из четырех (из примера) или полутора десятков (в реальности) состояний.

_>И? ) Не пойму с чем ты споришь то? ) Я разве утверждал, что весь твой пример можно покрыть статикой? )

На данный момент я спорю с твоим странным утверждением о «функциях состяний» и прочем, извини, бреде, который при малейшем толчке рассыпается в прах.

Ты взял удобный тебе пример, когда все подряд идет подряд и показываешь, как это мегакруто. Извини. На практике ничего подобного не бывает.

Данные получаются откуда угодно, но только не из этапа компиляции, объекты находятся в сотне изменяемых и неизменяемых состяний, часто противоречащих друг другу, и эти состояния зависят от нескольких десятков разнообразных параметров, половина которых — из базы данных, вторая — из-за конфигурации, а третья — из выставленных где-нибудь в GUI оверрайдов.

В итоге и получается: как только удобные вам примеры уровня hello world'а, то — ура, ура, посмотри какая статика крутая. Как только пытаешься выйти за пределы уютного мирка, где все известно заранее, на этапе компиляции, как все: «не, ну мы тебе ничего не обещали, тут дальше очевидно, достаточно сделать метасвойство» и прочая и прочая

_>Естественно там останется куча рантайм проверок. Я просто поясняю, что статические тоже будут встречаться и не так редко, как ты думаешь. Но всё же наверное недостаточно часто, чтобы делать подобное в твоём случая. А вот в других задачах, где процент повыше, это уже явно имеет смысл.

Так приведи эти задачи. Где они? Ну, такие, не сугубо теоретические, а что-то связанное с тем, чем тут большинство занимается: перекладыванием одних данных в другие. Опять же, рядом где-то на сотой странице обсуждений смогли осилить только boost timer, где афинные преобразования применяются (я, правда, не понял, в чем именно там проявляется мощь стат. типизации, ну да ладно)

_>Однако тут то у нас форум и вопрос стоял (как я понял) не в несообразности применения данной технологии к конкретной задаче, а в демонстрации самой возможности подобного и механизма действия. С этим вроде как мой пример полностью справляется.

Нет, не справляется. Потому что моментально рассыпается от малейших прикосновений:
— у нас нет прямого перехода от sendorder в decrease и т.п.
— у нас order не создается на этапе компиляции, а из 100% рантайм-данных, после чего кладется в базу
и т.п.



Пока что «примеры, прекрасно показывающие», имеют какие-то сугубо теоретические основы или странные требования.