J>>>Если да, то в каких случаях каждое из них можно звать, а в каких — нельзя?
M>>Прочти задачу
J>Ну, хозяин-барин. Всего хорошего.
То есть я уже виноват в том, что ты не способен прочитать задачу, написанную простым языком?
То есть ты банально не осилил следующее, а я виноват?
jazzer: Раз это всё действия, а не просто проверки, ты можешь добавить в описание свой задачи список действий и предусловий на них?
Задача, например пункт первый:
— если заказ неотправлен и непредоплачен, можно увеличивать и уменьшать (предусловие)
— если заказ отправлен, нельзя увеличивать, можно уменьшать (предусловие)
— если сумма увеличивается, мы должны провести risk check. если risk check не проходит, товар никак не помечается, но изменение суммы не проходит (предусловие и действие)
— если товар помечен, как risk, то изменять сумму нельзя (предусловие)
jazzer: Я правильно понял, что, помимо increase_amount, еще есть действия risk check, auth запрос, capture запрос? Если да, то в каких случаях каждое из них можно звать, а в каких — нельзя?
Задача, например третий пункт:
Шаг 3.
Все то же самое, что и в шаге 2. Дополнительно:
— если заказ предоплачен (неважно, отправлен или нет), можно увеличивать сумму, если это разрешено конфигурацией магазина. Сумма, на которую можно увеличивать высчитывается, как в шаге 2
— если заказ предоплачен, неотправлен, и сумма увеличивается, надо сделать auth-запрос в банк. если он не срабатывает, увеличить нельзя.
— если заказ предоплачен, отправлен, и сумма увеличивается, надо сделать auth-запрос в банк на разницу в сумме, а потом сделать capture запрос на всю сумму. Если хоть один из них не срабатывает, увеличить нельзя.
Все описано. Все последовательности, все предусловия, все условия, все «ad-hoc изменения». Нет. «Я тебя не понял»
J>>>Давай я еще раз задам вопросы, котрые ты стер — у тебя не займет много времени на них ответить: J>>>
J>>>Непонятно, как я добавлял второе свойство? Если так, то с этого надо было начинать. Что конкретно непонятно?
M>>Я пять раз задал тебе один и тот же вопрос. Ты так и не осилил ни ответить на него, ни привести свое решение.
J>То есть даже да/нет не можешь ответить? ОК, уровень конструктивности понятен. Sapienti sat.
Вот, что я тебе задавал раз пять только в этой подветке
Я хочу увидеть это «метасвойство». Я хочу увидеть, как решается заявленное тобой «типы помогают при ad-hoc дизайне», ведь именно для этого в моей задаче три шага.
Я хочу увидеть, что да, действительно, после реализации «метасвойства», после которого «таким образом мы вернемся к простому первоначальному варианту», мы действительно вернемся к простому варианту, после которого можно будет действительно сказать, что «не сказать, что кода стало на 100500 порядков больше».
Покажи мне, где там пример кода мета-свойства IncreaseAmountOK, и как его использовать.
Покажи мне пошагово, как и где твой код, реализующий шаг 1 легким движением руки превращается в код, реализующий шаг два (напомню: именно ты говорил о том, что типы позволяют легко справляться с ad-hoc изменениями). Почему у тебя все заканчивается строго и исключительно на «там дальше просто/очевидно/поянтно»?
Proof of concept с двумя условиями. Не решает даже первого пункта из моей задачи. Заканчивается на «ну там все легко/понятно/очевидно». Когда спрашиваешь: «мне не понятнои не очевидно, можно увидеть это развернутее», получаю раз за разом «что тебе там непонятно»
Могу во второй раз спросить: покажи мне, пожалуйста, реализацию того самого «очевидно понятного мета-свойства IncreaseAmountOK», желательно в сочетании с кодом, чтобы можно было увидеть, как все эти заявления работают на практике?
Ты уже в десятый раз говоришь о том, что, мол, в статье все написано. Заметь, я уже несколько раз тебе пишу:
Покажи мне, где там пример кода мета-свойства IncreaseAmountOK, и как его использовать.
Можно наконец-то увидеть это решение? Хоть мегасвойством хоть комбинацией? Я слышу много разговоров о том, как это можно решить и ноль решений
Да. Мне непонятно, как это решить, несмотря на тот кусок кода, что ты привел ПОтому что твой кусок кода не отвечает на вопросы:
— что будет, когда условий больше двух
— как реализовать то самое «мета-свойство»
Да. Мне непонятно. Я вижу распухающий от этих типов и PROP_IF'ов код, за которым не видно не то, что леса, но даже того, что вообще в коде происходит. Я зотел бы увидеть законченный код То есть где не только «добавлено третье-четвертое свойство» в тип, но и есть код, который с этими типами работает
и так далее...
Хотя учитывая, что ты даже не смог понять задачу, описанную простым и ясным языком, неудивительно, что ты не понял ни одного моего вопроса
Когда в следующий раз будешь говорить об уровне конструктива, смотри в зеркало.
Здравствуйте, Mamut, Вы писали:
M>Этот твой примерчик даже близко не сможет реализовать мой «простейший пример». Ну и не реализовал, как видим. Но гонора-то, гонора!
Никто и не пытался решать за тебя твою задачку. Все писали демонстрации различных техник, используя твою тематику. Для понимания нормальным специалистом этого более чем достаточно.
Ну и описание твоего примера не полно, т.к. не указано устройство окружающего мира: кто и как использует твои элементарные функции и т.п. Если у тебя всё происходит только в режиме "прочитали ордер из БД, увеличили сумму (если предусловия позволяют), записали ордер в БД", то мой пример действительно ничего интересного не демонстрирует. Т.е. он всё равно работает и решает поставленную тобой задачу, но при этом не даёт никаких бонусов (типа уменьшения числа рантайм проверок и т.п.), хотя и увеличивает объём кода — очевидно такое не имеет особого смысла. Если же у тебя там где-то встречается больше одной элементарной операции на транзакцию, то как раз мой пример реально демонстрирует преимущества подобной техники. И чем сложнее алгоритм (набор элементарных операций над ордером в рамках одной транзакции), тем больше будет преимущество.
M>Ты перечитай мой
«простейший пример с предусловиями» и все таки попробуй его реализовать своей статической типизацией. Благо, у меня там есть «подряд идут три элементарные операции, а не одна».
M>Вы все решаете какие-то свои простейшие примеры уровня «hello, world», но при этом уверены, что они сложнее, чем моя задача. Ты сделай усилие и почитай мою задачу. Там есть и предусловия, и последовательность действий, зависящая от этих предусловий (надо сделать risk check, auth запрос, capture запрос, увеличить сумму), и ad-hoc изменения требований... Ну то есть ровным счетом все то, в чем, согласно вашим многочисленным заявлениям, стат. типизация прекрасно помогает.
Нет у тебя нигде ни нескольких операций, ни одной операции, ни чего-либо ещё. У тебя вообще вопрос применения твоих функций полностью обойдён стороной. Ну т.е. это в собственно твоём описание задачки. А после, ты уже начал требовать определённую схему применения — как раз ту единственную, где применение демонстрируемых техник не приносит особо заметных плюсов. )))
Да, и "risk check", "auth запрос" и т.п. не являются элементарными операциями, т.к. действуют не над ордерами — это просто обычные проверки. Так что из них никакие цепочки операций не строятся.
О, и кстати... В моём простеньком примере польза от уменьшения компилятором числа рантайм проверок имеет только "философский" смысл, а на практике очевидно абсолютно не ощутимо (там собственно один if с целочисленным сравнением). А вот в случае появления сложных проверок, возможно делающих какие-то внешние запросы и соответственно долго выполняющихся (как раз как у тебя похоже), это уже обретает реальный смысл.
Re[106]: Haskell нужен! (в Standard Chartered Bank)
M>>Этот твой примерчик даже близко не сможет реализовать мой «простейший пример». Ну и не реализовал, как видим. Но гонора-то, гонора! _>Никто и не пытался решать за тебя твою задачку. Все писали демонстрации различных техник, используя твою тематику.
Перевод: все писали только то, что они осилили. Все примеры — уровня hello, world.
_>Ну и описание твоего примера не полно, т.к. не указано устройство окружающего мира: кто и как использует твои элементарные функции и т.п.
Для решения моей задачи это не нужно.
_>Если у тебя всё происходит только в режиме
Ты уже один раз осиль и прочти условие задачи. А то выглядишь, как jazzer
.
_>И чем сложнее алгоритм (набор элементарных операций над ордером в рамках одной транзакции), тем больше будет преимущество.
Слушай, ну хватит сказки рассказывать, а? Вы не осилили решение достаточно простого алгоритма, но утверждаете, что, якобы, на сложном алгоритме вот прямо-таки будет видно преимущество
M>>Вы все решаете какие-то свои простейшие примеры уровня «hello, world», но при этом уверены, что они сложнее, чем моя задача. Ты сделай усилие и почитай мою задачу. Там есть и предусловия, и последовательность действий, зависящая от этих предусловий (надо сделать risk check, auth запрос, capture запрос, увеличить сумму), и ad-hoc изменения требований... Ну то есть ровным счетом все то, в чем, согласно вашим многочисленным заявлениям, стат. типизация прекрасно помогает.
_>Нет у тебя нигде ни нескольких операций, ни одной операции, ни чего-либо ещё.
Ага. То есть ты как jazzer. Не осилил даже задачу прочитать. Там есть несколько операций. Для этого достаточно прочитать задачу, а не фантазировать на ее тему.
_>О, и кстати... В моём простеньком примере польза от уменьшения компилятором числа рантайм проверок имеет только "философский" смысл, а на практике очевидно абсолютно не ощутимо (там собственно один if с целочисленным сравнением). А вот в случае появления сложных проверок
Здравствуйте, Mamut, Вы писали:
_>>Ну и описание твоего примера не полно, т.к. не указано устройство окружающего мира: кто и как использует твои элементарные функции и т.п. M>Для решения моей задачи это не нужно.
Для формального факта решения задачи действительно не нужно. Но решить её можно десятками разных способов (вот например возьму я и интегрирую какой-нибудь движок специализированного dsl) и определиться с тем, какой способ самый эффективный, можно только имя полную картину использования данного решения.
_>>Если у тебя всё происходит только в режиме M>Ты уже один раз осиль и прочти условие задачи. А то выглядишь, как jazzer
У тебя в условие задачи нет ни одного слова про то, сколько элементарных операций над ордерами происходит за одну транзакцию.
_>>И чем сложнее алгоритм (набор элементарных операций над ордером в рамках одной транзакции), тем больше будет преимущество. M>Слушай, ну хватит сказки рассказывать, а? Вы не осилили решение достаточно простого алгоритма, но утверждаете, что, якобы, на сложном алгоритме вот прямо-таки будет видно преимущество
Я тебе показал компилируемый пример. Если тебе этого недостаточно для понимания, то это уже не моя проблема. )
_>>Нет у тебя нигде ни нескольких операций, ни одной операции, ни чего-либо ещё. M>Ага. То есть ты как jazzer. Не осилил даже задачу прочитать. Там есть несколько операций. Для этого достаточно прочитать задачу, а не фантазировать на ее тему.
Я пример уже привёл. Изменение предусловия с простейшего на более сложное (например обращающееся к сети, как вроде бы у тебя и есть в определённых случаях) абсолютно не изменит устройство моего примера. Просто при этом применение данной техники покажет уже вполне ощутимое на практике изменение в быстродействие...
Re[96]: Haskell нужен! (в Standard Chartered Bank)
Ты это и так делаешь все это время, не вижу, чтобы что-то изменилось, если ты это начнешь делать с предварительным объявлением.
M>Чувствую, что твое обещание решить задачу в апреле я тоже так и не дождусь
Вообще-то да, я не вижу смысла напрягаться ради человека, который открыто демонстрирует свое неуважение ко мне. Тебе это уже говорили многие и много раз, но тебе либо пофиг, либо этого ты и добиваешься. Всего хорошего.
M>>Чувствую, что твое обещание решить задачу в апреле я тоже так и не дождусь
J>Вообще-то да, я не вижу смысла напрягаться ради человека, который открыто демонстрирует свое неуважение ко мне. Тебе это уже говорили многие и много раз, но тебе либо пофиг, либо этого ты и добиваешься. Всего хорошего.
Я, вообще-то, уважаю всех. Пока не оказывается, что на протяжение 100 страниц все скатывается только в демагогию, а потом ВНЕЗАПНО оказывается, что логика не та, задача не та, ты не осилил прочитать даже условие задачи, предусловия не те и т.п.
Я тебя сколько — пять? — раз просил простейшее: не фантазировать на тему моей задачи, а решить хотя бы первый пункт из нее и показать мне, как реализуется метасвойство IncreaeAmountOk. Свои ответы ты можешь сам посмотреть.
И после этого ты еще заикаешься о каком-то уважении, ага.
_>>>Ну и описание твоего примера не полно, т.к. не указано устройство окружающего мира: кто и как использует твои элементарные функции и т.п. M>>Для решения моей задачи это не нужно.
_>Для формального факта решения задачи действительно не нужно. Но решить её можно десятками разных способов (вот например возьму я и интегрирую какой-нибудь движок специализированного dsl) и определиться с тем, какой способ самый эффективный, можно только имя полную картину использования данного решения.
. _>У тебя в условие задачи нет ни одного слова про то, сколько элементарных операций над ордерами происходит за одну транзакцию.
Ага. То есть на 100500 странице обсуждений мы ВНЕЗАПНО выясняем границы применимости вашего подхода:
— это не логика (неизвестно, что вы считаете логикой)
— предусловия не те (неизвестно, что вы считаете теми)
— действия не те (неизвестно, что вы считаете теми)
являются просто сказками. Спасибо.
_>>>И чем сложнее алгоритм (набор элементарных операций над ордером в рамках одной транзакции), тем больше будет преимущество. M>>Слушай, ну хватит сказки рассказывать, а? Вы не осилили решение достаточно простого алгоритма, но утверждаете, что, якобы, на сложном алгоритме вот прямо-таки будет видно преимущество
_>Я тебе показал компилируемый пример. Если тебе этого недостаточно для понимания, то это уже не моя проблема. )
Твой пример даже близко не решает поставленную задачу, и как из него следует, что на «сложных алгоритмах будет видно преимущество», неизвестно. Ведь:
— вы не осилили даже «простой» алгоритм
— ты не смог дать определение «более сложного» алгоритма
_>>>Нет у тебя нигде ни нескольких операций, ни одной операции, ни чего-либо ещё. M>>Ага. То есть ты как jazzer. Не осилил даже задачу прочитать. Там есть несколько операций. Для этого достаточно прочитать задачу, а не фантазировать на ее тему.
_>Да, у тебя есть несколько операций (типа изменить сумму, установить флаг риска, отправленно и т.п.). Но у тебя не указано, как эти операции используются (какие последовательности из них встречаются в ваших алгоритмах).
Ты опять ршаешь не поставленную задачу, а какие-то фантазии на тему этой задачи. Считай, что это — API вызов, который вызывается откуда. Или ты как jazzer иЕвгений
_>Я пример уже привёл. Изменение предусловия с простейшего на более сложное (например обращающееся к сети, как вроде бы у тебя и есть в определённых случаях) абсолютно не изменит устройство моего примера. Просто при этом применение данной техники покажет уже вполне ощутимое на практике изменение в быстродействие...
Демагогия, демагогия, демагогия. Пока что я вижу вот это
Твой «примерчик» моментально разваливается для моей задачи. Потому что твой «примерчик» способен только обработать именно что только простейшую последовательность простейших операций. Как только между этими операциями появляются хоть какие-то условия (как в моем примере, шаг 3, например), все твои заявления про «последовательности операций» и «сложные алгоритмы» вылетают в трубу.
Здравствуйте, Mamut, Вы писали:
_>>У тебя в условие задачи нет ни одного слова про то, сколько элементарных операций над ордерами происходит за одну транзакцию.
M>Ага. То есть на 100500 странице обсуждений мы ВНЕЗАПНО выясняем границы применимости вашего подхода: M>- это не логика (неизвестно, что вы считаете логикой) M>- предусловия не те (неизвестно, что вы считаете теми) M>- действия не те (неизвестно, что вы считаете теми)
M>
M>То есть все ваши сказки
Ммм, а как интересно этот мутный поток мыслей связан с моей чёткой фразой о нехватке одного нюанса в твоём описание задачи?
_>>Я тебе показал компилируемый пример. Если тебе этого недостаточно для понимания, то это уже не моя проблема. )
M>Твой пример даже близко не решает поставленную задачу, и как из него следует, что на «сложных алгоритмах будет видно преимущество», неизвестно. Ведь: M>- вы не осилили даже «простой» алгоритм M>- ты не смог дать определение «более сложного» алгоритма
Вообще то именно этот пример и демонстрирует "сложный алгоритм". Потому как в данном контексте под "сложным алгоритмом" подразумевалось всего лишь более одной элементарной операции на транзакцию. А в том моём примере показана демонстрация с 3-мя операциями на транзакцию. И в нём чётко видно, что одна из проверок времени исполнения переместилась во время компиляции.
_>>Да, у тебя есть несколько операций (типа изменить сумму, установить флаг риска, отправленно и т.п.). Но у тебя не указано, как эти операции используются (какие последовательности из них встречаются в ваших алгоритмах).
M>Ты опять ршаешь не поставленную задачу, а какие-то фантазии на тему этой задачи. Считай, что это — API вызов, который вызывается откуда. Или ты как jazzer иЕвгений
Ну так тут как раз дело в том, что если при использование данного API будут происходить вызовы нескольких функций подряд, то может быть эффективнее один подход, а если не будут, то другой.
M>Твой «примерчик» моментально разваливается для моей задачи. Потому что твой «примерчик» способен только обработать именно что только простейшую последовательность простейших операций. Как только между этими операциями появляются хоть какие-то условия (как в моем примере, шаг 3, например), все твои заявления про «последовательности операций» и «сложные алгоритмы» вылетают в трубу.
Повторюсь ещё раз: данный подход применим вообще для любого случая и любой задачи. Просто процент перемещённых во время компиляции проверок будет разный.
Re[110]: Haskell нужен! (в Standard Chartered Bank)
M>>Ага. То есть на 100500 странице обсуждений мы ВНЕЗАПНО выясняем границы применимости вашего подхода: M>>- это не логика (неизвестно, что вы считаете логикой) M>>- предусловия не те (неизвестно, что вы считаете теми) M>>- действия не те (неизвестно, что вы считаете теми)
M>>
M>>То есть все ваши сказки
являются просто сказками. Спасибо.
_>Ммм, а как интересно этот мутный поток мыслей связан с моей чёткой фразой о нехватке одного нюанса в твоём описание задачи?
Извини, но у меня очень четкий и понятный поток мыслей. В отличие от. Чем тебе не нравится последовательность действий в моей задаче?
_>>>Я тебе показал компилируемый пример. Если тебе этого недостаточно для понимания, то это уже не моя проблема. )
M>>Твой пример даже близко не решает поставленную задачу, и как из него следует, что на «сложных алгоритмах будет видно преимущество», неизвестно. Ведь: M>>- вы не осилили даже «простой» алгоритм M>>- ты не смог дать определение «более сложного» алгоритма
_>Вообще то именно этот пример и демонстрирует "сложный алгоритм".
Ахахаха. Вообще-то, не демонстрирует. Твой пример демонстрирует уровень "hello, world".
_>Потому как в данном контексте под "сложным алгоритмом" подразумевалось всего лишь более одной элементарной операции на транзакцию.
Пожалуйста,в моей задаче в третьем шаге есть больше одного элементарного дейтсвия. Пожалуйста, продемонстрируй, как твой, цитрую, «подход, который применим вообще для любого случая и любой задачи», решает не твою задачу hellow, world, а мою задачу, которая настолько сложнее, что вы всем скопом уже месяц не можете ее решить.
M>>Ты опять ршаешь не поставленную задачу, а какие-то фантазии на тему этой задачи. Считай, что это — API вызов, который вызывается откуда. Или ты как jazzer иЕвгений
?
_>Ну так тут как раз дело в том, что если при использование данного API будут происходить вызовы нескольких функций подряд, то может быть эффективнее один подход, а если не будут, то другой.
Я же говорю, ты продолжаешь решать не мою задачу, а свои фантазии на тему моей задачи. То есть, ты превращаешься в Евгения: http://rsdn.ru/forum/philosophy/5973616
Здравствуйте, Mamut, Вы писали:
_>>Ммм, а как интересно этот мутный поток мыслей связан с моей чёткой фразой о нехватке одного нюанса в твоём описание задачи? M>Извини, но у меня очень четкий и понятный поток мыслей. В отличие от. Чем тебе не нравится последовательность действий в моей задаче?
С задачей всё нормально как раз (ну если не считать отсутствие описания стратегии использования). Это была речь о списке невнятных претензий в цитате выше. Которые к тому же не имеют ко мне вообще никакого отношения.
_>>Вообще то именно этот пример и демонстрирует "сложный алгоритм". M>Ахахаха. Вообще-то, не демонстрирует. Твой пример демонстрирует уровень "hello, world".
Хм, для тебя открытие, что для примера технологии лучше всего демонстрировать максимально простой случай?
M>Пожалуйста,в моей задаче в третьем шаге есть больше одного элементарного дейтсвия. Пожалуйста, продемонстрируй, как твой, цитрую, «подход, который применим вообще для любого случая и любой задачи», решает не твою задачу hellow, world, а мою задачу, которая настолько сложнее, что вы всем скопом уже месяц не можете ее решить.
Я уже всё продемонстрировал на эту тему (когда имеем более одной элементарной операции на транзакцию) — компилируемого примера более чем достаточно для понимания. Вот для случая "одна операция на транзакцию", который ты в последнее время стал навязывать, эта техника действительно не сработает (т.е. код то работать будет, но не лучше варианта в лоб), так что тут можно подумать о других вариантах использования статической типизации. Например какой-то автоматический контроль наличия проверок (а не перенос их во время компиляции) и т.п. Вроде как пример jazzer'а можно использовать там, хотя не уверен (не пробовал его код на практике). Ну собственно я уже говорил, что на эту тему я решение ещё продумывал. )
M>Я же говорю, ты продолжаешь решать не мою задачу, а свои фантазии на тему моей задачи. То есть, ты превращаешься в Евгения: http://rsdn.ru/forum/philosophy/5973616
_>>>Ммм, а как интересно этот мутный поток мыслей связан с моей чёткой фразой о нехватке одного нюанса в твоём описание задачи? M>>Извини, но у меня очень четкий и понятный поток мыслей. В отличие от. Чем тебе не нравится последовательность действий в моей задаче?
_>С задачей всё нормально как раз (ну если не считать отсутствие описания стратегии использования). Это была речь о списке невнятных претензий в цитате выше. Которые к тому же не имеют ко мне вообще никакого отношения.
Вот смотри.
Задача полностью соответсвует всем критериям, которые вы мне тыт выдвигаете:
— в ней есть предусловия, которые так хочет Евгений Панасюк
— в ней есть условия и ad-hoc изменения, которые хочет jazzer
— в ней есть последовательность условий, которые требуешь ты
После сотни страниц демагогии, внезапно оказывается, что:
— предусловия не такие (Евгений)
— там не логика, там миллион условий, задача непонятна (jazzer)
— там последовательность условий не такая, нужно знать стратегии использования (ты)
_>>>Вообще то именно этот пример и демонстрирует "сложный алгоритм". M>>Ахахаха. Вообще-то, не демонстрирует. Твой пример демонстрирует уровень "hello, world". _>Хм, для тебя открытие, что для примера технологии лучше всего демонстрировать максимально простой случай?
Молодец. Продемоснтрировал. Я задаю вопрос, усложняющий пример. Ответа не могу получить уже два месяца.
M>>Пожалуйста,в моей задаче в третьем шаге есть больше одного элементарного дейтсвия. Пожалуйста, продемонстрируй, как твой, цитрую, «подход, который применим вообще для любого случая и любой задачи», решает не твою задачу hellow, world, а мою задачу, которая настолько сложнее, что вы всем скопом уже месяц не можете ее решить.
_>Я уже всё продемонстрировал на эту тему
Ты ничего не продемонстрировал, кроме примитивнейшей последовательности действий. Ты и близко не продемонстрировал даже решение первого, самого простого, пункта моей задачи. Я умолчу про решение третьего.
_>(когда имеем более одной элементарной операции на транзакцию) — компилируемого примера более чем достаточно для понимания. Вот для случая "одна операция на транзакцию", который ты в последнее время стал навязывать
Прекрати фантазировать. Я ничего не навязываю. Я два месяца подряд последовательно пытаюсь добиться одного и того же. Не моя проблема, что вы отвечаете не на мои вопросы, а непонятно, на что
_>, эта техника действительно не сработает
данный подход применим вообще для любого случая и любой задачи.
Еще раз.
В задаче есть: условия и последовательность действий. Только вот незадача, какая именно последовательность, зависит от этих же условий. Я не прошу многого, я прошу продемонстрировать только одно: как в этих условиях будет работать ваша хваленая стат. типизация, которая «применима вообще для любого случая и любой задачи»
Нафига тебе надо знать «стратегию условия» этого вызова? У тебя есть сам вызов с последовательностью действий. Считай, что это — API вызов, который вызывается из 50-и мест. И внутри него происходит, цитируя тебя, «последовательность элементарных операций»
Повторю еще раз. Ты не смог даже понять условие задачи, а решаешь какие-то свои фантазии на тему этой задачи. Поэтому тебе нужны «стратегии использования», все эти «send order» и т.п. На.фи.га? Ты неспособен решить поставленную задачу без этого? Почему?
Здравствуйте, Mamut, Вы писали:
M>Вот смотри.
M>Задача полностью соответсвует всем критериям, которые вы мне тыт выдвигаете:
M>- в ней есть предусловия, которые так хочет Евгений Панасюк M>- в ней есть условия и ad-hoc изменения, которые хочет jazzer M>- в ней есть последовательность условий, которые требуешь ты
Я тебе уже раз 10 говорил, что нужна последовательность операций, а не условий (сложность условия вообще никак не влияет). Если ты до сих пор этого не понял, то я умываю руки...
M>После сотни страниц демагогии, внезапно оказывается, что: M>- предусловия не такие (Евгений) M>- там не логика, там миллион условий, задача непонятна (jazzer) M>- там последовательность условий не такая, нужно знать стратегии использования (ты)
M>
У тебя там не "не такая" последовательность условий, а просто неизвестно какая — она просто не указана в описание задачи. )))
M>Молодец. Продемоснтрировал. Я задаю вопрос, усложняющий пример. Ответа не могу получить уже два месяца.
Ну так ты тогда добавь ещё уточнение условий, про которое я говорил.
M>Ты ничего не продемонстрировал, кроме примитивнейшей последовательности действий. Ты и близко не продемонстрировал даже решение первого, самого простого, пункта моей задачи. Я умолчу про решение третьего.
Ммм, а что значит не продемонстрировал решение? ) Вообще то как раз демонстрация есть. Более того, этот код будет работать и для случая "одной элементарной операции на транзакцию". Просто в этом случае он будет полностью аналогичен (в рантайме) твоему коду в лоб, так что нет никакого смысла в этом случае возиться.
_>>(когда имеем более одной элементарной операции на транзакцию) — компилируемого примера более чем достаточно для понимания. Вот _>>, эта техника действительно не сработает M>
M>данный подход применим вообще для любого случая и любой задачи.
Я вроде бы уже несколько раз говорил. Код будет работать вообще в любом случае. Но в самом вырожденном случае (одна операция на транзакцию) он будет полностью аналогичен (в рантайме) твоему коду в лоб. В других же случаях часть рантайм проверок перейдёт во время компиляции (именно я и называю "срабатыванием" техники). Процент перехода зависит от устройства и сложности алгоритма.
M>Нафига тебе надо знать «стратегию условия» этого вызова? У тебя есть сам вызов с последовательностью действий. Считай, что это — API вызов, который вызывается из 50-и мест. И внутри него происходит, цитируя тебя, «последовательность элементарных операций»
M>Повторю еще раз. Ты не смог даже понять условие задачи, а решаешь какие-то свои фантазии на тему этой задачи. Поэтому тебе нужны «стратегии использования», все эти «send order» и т.п. На.фи.га? Ты неспособен решить поставленную задачу без этого? Почему?
Ну если ты не смог понять этого после всех моих пояснений, то я не вижу смысла продолжать эту дискуссию...
Re[112]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Mamut, Вы писали:
_>>>Ммм, а как интересно этот мутный поток мыслей связан с моей чёткой фразой о нехватке одного нюанса в твоём описание задачи? M>>Извини, но у меня очень четкий и понятный поток мыслей. В отличие от. Чем тебе не нравится последовательность действий в моей задаче?
_>С задачей всё нормально как раз (ну если не считать отсутствие описания стратегии использования). Это была речь о списке невнятных претензий в цитате выше. Которые к тому же не имеют ко мне вообще никакого отношения.
_>>>Вообще то именно этот пример и демонстрирует "сложный алгоритм". M>>Ахахаха. Вообще-то, не демонстрирует. Твой пример демонстрирует уровень "hello, world".
_>Хм, для тебя открытие, что для примера технологии лучше всего демонстрировать максимально простой случай?
Это, видимо, как с юнит-тестами. Пока мы тестируем сложение двух чисел — все нормально. Как только нужно тестировать чуть более сложное поведение, например вполне чистую реализацию какого-нибудь хитрого алгоритма, мы сразу попадаем на то, что нужны функциональные тесты, а не вот это вот. Простые случаи как раз неинтересны, если только не заниматься исключительно такими задачами.
Re[103]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, m.aksenov, Вы писали:
MA>А можно пример цепочки преобразований, где это реально поможет? Ну, то есть я примерн представляю развесистый бизнес-процесс с кучей шагов, но это ж на каждом шаге будет новый тип (для гарантированных проверок). А это для одной (логически) сущности мы создаем десятки типов на _каждый_ сложный бизнес-процесс. Стоит оно того? Для тех самых "сложных" случаев.
В моем примере никаких десятков типов не создается, есть обобщенный один тип-контейнер "тип со свойствами". Так что нет никакой необходимости рожать руками толпу типов, нужны только свойства. Соответственно, на входе у функций проверяется не конкретный тип, а лишь наличие нужных свойств (а какие там другие свойства — пофиг).
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, m.aksenov, Вы писали:
MA>>А можно пример цепочки преобразований, где это реально поможет? Ну, то есть я примерн представляю развесистый бизнес-процесс с кучей шагов, но это ж на каждом шаге будет новый тип (для гарантированных проверок). А это для одной (логически) сущности мы создаем десятки типов на _каждый_ сложный бизнес-процесс. Стоит оно того? Для тех самых "сложных" случаев.
J>В моем примере никаких десятков типов не создается, есть обобщенный один тип-контейнер "тип со свойствами". Так что нет никакой необходимости рожать руками толпу типов, нужны только свойства. Соответственно, на входе у функций проверяется не конкретный тип, а лишь наличие нужных свойств (а какие там другие свойства — пофиг).
Строго говоря, типы получаются разные, поскольку обладают разными свойствами в разных местах программы
Другое дело, что подход интересный, но выглядит как шаманство (у меня очень ограниченный опыт использования современного С++). К сожалению, проверки в рантайме (и тесты, разумеется) это целиком не заменит, но может быть статически верифицируемые места и позволит обезопасить. Нужно будет в старом Скала-проекте попробовать что-то такое замутить. С ее системой типов это будет может и поинтереснее даже.
В любом случае, за пример спасибо.
Re[105]: Haskell нужен! (в Standard Chartered Bank)
Здравствуйте, m.aksenov, Вы писали:
MA>Строго говоря, типы получаются разные, поскольку обладают разными свойствами в разных местах программы
Ну, к шаблонам по-разному можно относиться.
В моем случае происходит переписывание типа после каждой проверки, отражающее факт того, что проверка была произведена, и результат оной. Но это все происходит "под капотом", наружу изменение типа не торчит, а главный тип остается прежним.
Рулез в том, что ты мог проверить десяток условий, и у тебя навесится десяток разных свойств, но каждая функция, которую ты зовешь для финального объекта, будет смотреть только на те свойства, которые ей нужны, и игнорировать другие. Так что для них это разнообразие типов будет сводиться к дихотомии "есть или нет в тип набор свойств, который мне нужен".
MA>Другое дело, что подход интересный, но выглядит как шаманство (у меня очень ограниченный опыт использования современного С++). К сожалению, проверки в рантайме (и тесты, разумеется) это целиком не заменит, но может быть статически верифицируемые места и позволит обезопасить. Нужно будет в старом Скала-проекте попробовать что-то такое замутить. С ее системой типов это будет может и поинтереснее даже.
Так я и не утверждал, что они заменят рантайм-проверки. Они не для того, чтоб их заменить, а для того, чтобы не позволить их пропустить и позвать функцию, которую звать без предварительной проверки нельзя. Т.е. вызов sqrt(x) является ошибкой программиста, если x<0. Если ее объявить как требующую для x свойство Nonnegative — то компилятор не пропустит вызов без соответствующей проверки. При этом не обязательно делать именно проверку, можно это гарантировать иначе, например, функция модуля fabs будет автоматом навешивать это свойство на свой результат — и тогда его можно сразу закидывать в sqrt напрямую.
_>Я тебе уже раз 10 говорил, что нужна последовательность операций, а не условий (сложность условия вообще никак не влияет). Если ты до сих пор этого не понял, то я умываю руки...
Последовательность операций есть.
_>У тебя там не "не такая" последовательность условий, а просто неизвестно какая — она просто не указана в описание задачи. )))
Она прекрасно указана в задаче. Если ты не способен (как и jazzer) наконец0-то сесть и прочитать ее, это не мои проблемы
Там есть: risk check, auth, capture, increase (или decrease) amount
_>Ммм, а что значит не продемонстрировал решение? ) Вообще то как раз демонстрация есть. Более того, этот код будет работать и для случая "одной элементарной операции на транзакцию".
Ты опять фантазируешь на темы задачи и активно борешься со своими фантазиями
_>Ну если ты не смог понять этого после всех моих пояснений, то я не вижу смысла продолжать эту дискуссию...
У тебя нет пояснений. У тебя есть какое-то упорное желание фантазировать на темы. «Ах-ах-ах, вот тебе пример, там есть три действия подряд с одним условием, это такая прекрасная демонстрация». Только это — фэнтезийный сферовакуумный теоретический пример. На практике между этими тремя действиями есть толпа условий. Каждое следующее действие вполне может зависеть от результата предыдущего действия. И как решается это, ни ты, ни кто либо другой так и не осилили показать. Несмотря на все высокопарные и пафосные заявления.
Здравствуйте, Mamut, Вы писали:
M>Она прекрасно указана в задаче. Если ты не способен (как и jazzer) наконец0-то сесть и прочитать ее, это не мои проблемы M>Там есть: risk check, auth, capture, increase (или decrease) amount
Ты уже определись, risk check, auth и т.п. — это отдельные операции над ордерами (т.е. меняют их) или же просто какие-то условия на выполнение операций increase/decrease?
M>У тебя нет пояснений. У тебя есть какое-то упорное желание фантазировать на темы. «Ах-ах-ах, вот тебе пример, там есть три действия подряд с одним условием, это такая прекрасная демонстрация». Только это — фэнтезийный сферовакуумный теоретический пример. На практике между этими тремя действиями есть толпа условий. Каждое следующее действие вполне может зависеть от результата предыдущего действия. И как решается это, ни ты, ни кто либо другой так и не осилили показать. Несмотря на все высокопарные и пафосные заявления.
Ты действительно считаешь, что если в моём примере заменить
