Сообщение Re[74]: Haskell нужен! (в Standard Chartered Bank) от 27.02.2015 15:11
Изменено 27.02.2015 19:09 AlexRK
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
ARK>>Ну, это другой вопрос. Это не имеет значения, что мы там будем делать. Может просто вернем заказ в текущем виде.
S>Это называется "увиливать", или "юлить".
S>Потому, что честный человек бы просто признался, что в обычном "нетипизированном" increase_amount() мы просто сделаем ровно то же, что и в вашей якобы "магической" try_change_amount.
S>Например — вернём заказ в текущем виде.
S>Ваш ход?
Мы можем сделать кое-что поинтереснее. Например, сгенерировать ошибку времени компиляции.
Теперь у нас есть предусловие времени компиляции, гарантирующее, что на этапе исполнения функция try_to_change_amount вообще никогда не будет вызвана, если ее параметр предварительно не проверен (где-то выше) на HasRisk.
Сделайте "ровно то же" у себя.
Правда, вряд ли это получится.
S>Здравствуйте, AlexRK, Вы писали:
ARK>>Ну, это другой вопрос. Это не имеет значения, что мы там будем делать. Может просто вернем заказ в текущем виде.
S>Это называется "увиливать", или "юлить".
S>Потому, что честный человек бы просто признался, что в обычном "нетипизированном" increase_amount() мы просто сделаем ровно то же, что и в вашей якобы "магической" try_change_amount.
S>Например — вернём заказ в текущем виде.
S>Ваш ход?
Мы можем сделать кое-что поинтереснее. Например, сгенерировать ошибку времени компиляции.
void try_to_change_amount(Order& o)
{
PROP_IF(o, has_risk(o), !HasRisk) {
BOOST_MPL_ASSERT_MSG(false, YOU_CANT_INCREASE_AMOUNT_FOR_SUCH_ORDER, (O));
};
... дальше обычный код
}Теперь у нас есть предусловие времени компиляции, гарантирующее, что на этапе исполнения функция try_to_change_amount вообще никогда не будет вызвана, если ее параметр предварительно не проверен (где-то выше) на HasRisk.
Сделайте "ровно то же" у себя.
Re[74]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
ARK>>Ну, это другой вопрос. Это не имеет значения, что мы там будем делать. Может просто вернем заказ в текущем виде.
S>Это называется "увиливать", или "юлить".
S>Потому, что честный человек бы просто признался, что в обычном "нетипизированном" increase_amount() мы просто сделаем ровно то же, что и в вашей якобы "магической" try_change_amount.
S>Например — вернём заказ в текущем виде.
S>Ваш ход?
Мы можем сделать кое-что поинтереснее. Например, сгенерировать ошибку времени компиляции.
Теперь у нас есть предусловие времени компиляции, гарантирующее, что на этапе исполнения функция try_to_change_amount вообще никогда не будет вызвана, если ее параметр предварительно не проверен (где-то выше) на HasRisk.
Сделайте "ровно то же" у себя.
Правда, вряд ли это получится.
S>Здравствуйте, AlexRK, Вы писали:
ARK>>Ну, это другой вопрос. Это не имеет значения, что мы там будем делать. Может просто вернем заказ в текущем виде.
S>Это называется "увиливать", или "юлить".
S>Потому, что честный человек бы просто признался, что в обычном "нетипизированном" increase_amount() мы просто сделаем ровно то же, что и в вашей якобы "магической" try_change_amount.
S>Например — вернём заказ в текущем виде.
S>Ваш ход?
Мы можем сделать кое-что поинтереснее. Например, сгенерировать ошибку времени компиляции.
void try_to_change_amount(Order& o)
{
PROP_IF(o, possibly_has_risk(o), HasRisk) {
BOOST_MPL_ASSERT_MSG(false, YOU_CANT_INCREASE_AMOUNT_FOR_SUCH_ORDER, (O));
};
... дальше обычный код
}Теперь у нас есть предусловие времени компиляции, гарантирующее, что на этапе исполнения функция try_to_change_amount вообще никогда не будет вызвана, если ее параметр предварительно не проверен (где-то выше) на HasRisk.
Сделайте "ровно то же" у себя.