Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, jazzer, Вы писали:
J>> Нет никакой реализации логики (т.е. реальных действий) на типах. На типах реализуются ограничения, J>> которым должен удовлетворять код. При этом в коде реализации самих ограничений могут быть ошибки, естественно. М>не совсем понятно где нет реализации логики. у вас или вообще на типах. если вообще на типах то с этим сложно согласиться.
именно. Мамут, вроде как, речь именно об этом ведет — что мы, как будто бы, утверждаем, что все можно перенести в типы и весь рантайм-код исчезнет.
М>если это не реализация логики на типах, то что это? это ни разу не есть ограничения операций над типами.
Это просто операции, связывающие разные типы. Но не логика на типах. Хотя, конечно, смотря что оной называть. На мой взгляд, логика на типах — это когда у тебя одни типы и, кроме них, ничего больше нет. То есть, например, логика на типах — это определение, какой тип лучше дешевле по ссылке, а какой — по значению, потому что компилятор может его (значение) целиком в регистр процессора засунуть. И тогда best_param_type<int>::type даст int, а best_param_type<string>::type даст string&. Вот это — логика на типах: тип взяли, тип вернули.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, jazzer, Вы писали:
J>>На типах пишется логика ограничений: когда, что и как может быть вызвано. J>>И проверяет их компилятор за нас, автоматически, и не пропустит ни строчки кода, не соответствующего требуемым (или изменившимся) ограничениям.
I>У тебя и проверка компилятором и проверки в рантайме.
они проверяют разное.
I>А хочется только первое без второго. То есть, что бы никаких проверок рантайме не было.
Ну мне тоже хочется, чтоб по щучему веленью.
М>>>хорошо, давайте поговорим о вашей задаче: M>>Не надо про мою задачу Пока что с ней никто, от слова вообще, не справился М>вы меня просто возбуждаете с ней справится. давайте попробуем, а?
Пожалуйста Я давно жду, чтобы хоть кто-то справился
M>>Охохонюшки. Опять только один статус и только одна проверка M>>Создавать десяток классов? М>почему нет? что вас останавливает?
То, что это сильно усложняет код, например М>я же тут пытаюсь на эмулировать машину состояний на том, что есть (типы). пускай каждый тип это узел, а его методы -- это функции перехода в другие состояния. ваша задача очень хорошо ложится на машину состояний. другой вопрос как ее реализовать? один из вариантов -- на типах. не знаю как элегантно наследовать классы в си++, но на питоне очень просто брать классы и плодить на основе их типы, при этом наследуются тонны кода и вы только правите поведенческую модель дерева в конкретных узлах. оно к тому же будет и быстро работать. что может быть быстрее машины состояний? если из состояния А возможен переход только в Б и Ц, то проверки на Е и Ф выбрасываются. меньше проверок -- больше скорость. да и машину состояний можно визуализировать, чтобы проверить насколько наша модель корректна.
Много текста ни о чем. Код в студию!
М>давайте (если вам интересно) попробуем решить вашу задачу на базе машины состояний, представив ее узлы различными типами (классами). увы, я не знаю эрланг. только си (но он тут не подходит), js, питон, руби и немного java.
Давайте. Я тут уже месяц жду, чтобы кто-то решил эту задачу
М>а все это время -- искали ошибки в коде и пробовали откатываться к образу системы взад. о такой коварной ошибке как лопнувший трубопровод никто и не думал. железо тестировали конечно. ночью. когда все расходились по домам. ну так ночью сервер работал без воды и потому отрабатывал все тесты производителя железа на отлично.
Это прекрасно Да, тут не поможет никто, кроме сантехника
М>и раз уж мы заговорили за кондиционеры... вообразите себе картину. в одном Y образном кубике рядом сидят два человека. одна -- девушка, которая чуть ли не раздетая до гола и рядом с ней мужик в зимней куртке, ежится от холода. а все потому что на мужика сверху льется поток переохлажденного воздуха, но система построена так, что до других он не доходит и остальным жарко. а что? клево так. отъехал в кресле на метр и ты уже на юге. вернулся на метр обратно и попал на крайний север.
M>>Не надо про мою задачу Пока что с ней никто, от слова вообще, не справился
ARK>Справедливости ради, я бы все же уточнил: ее просто никто не стал делать. ARK>"Не стал делать" и "не справился" это все же разное. ARK>Логически из первого второе не следует.
В том-то и дело, что именно не справился. Все представленное — это именно «вот эту задачу мы можем решить так, далее все очевидно». Зато воплей про тривиальность и пафос — в каждом первом сообщении
M>>Охохонюшки. Опять только один статус и только одна проверка У нас в рантайме все хорошо и без типов и трансляторов И да, у нас можно изменять сумму после отправки И условий, при которых нельзя — с десяток. Создавать десяток классов?
J>В моей версии класс для свойства — это строчка
struct AnotherClass;
Всё. Внутри даже не нужно ничего, никаких членов и прочая — нам нужно только уникальное имя. "Создавать десяток таких строчек" — вот ужас то
В твой версии вообще нет решения моей задачи. Я вот уже сколько — неделю? — жду, чтобы ты продемонстрировал, как реализовывать «там же все очевидно метакласс». И тишина
Здравствуйте, Mamut, Вы писали:
M>В том-то и дело, что именно не справился. Все представленное — это именно «вот эту задачу мы можем решить так, далее все очевидно».
J>именно. Мамут, вроде как, речь именно об этом ведет — что мы, как будто бы, утверждаем, что все можно перенести в типы и весь рантайм-код исчезнет.
Нет. Мамут пытается весь ваш пафос и сказки увидеть в деле. Вы, а не я, их рассказываете. В итоге никто не осилил простейшую задачу, рассказывая сказки, как все там очевидно и тривиально
нельзя будет сконструировать заказ с состоянием "Отправленный" и "Непроверенный как написано в 4-м пункте" одновременно, так что в случае забывания 4-го пункта будет ошибка компиляции.
Никто не реализовал даже первый пункт, не говоря уже о «четвертом»
Я и сам согласен на пример кода.
Напишите нетипизированную программу, приведите тестовые данные, тогда можно будет написать типизированную версию в качестве ответа.
Ахахаха. Привел. В ответ тишина.
О, а вот что говорил ты, jazzer:
Вот тут как раз и поможет компилятор — как раз с ad-hoc изменениями требований. Если раньше с processed order можно было делать все, что угодно, а потом вдруг "концепция поменялась" и amount у него больше менять нельзя — достаточно отразить это в определении типа, а дальше компилятор сам ткнет во все места, где код не соответствует новому определению
Только в итоге ты не осилил даже первый шаг из моего примера, что там говорить об ad-hoc на втором-третьем шаге. (Это не говоря про повторенную несколько раз бредятину про исключения и ошибки).
Типы не решают задачу решения задачи в лоб. Они решают задачу бана неправильного кода, где правильность закодирована в определении. У тебя такого бана нету. Можно проверить is_forbidden и тут же дернуть update_amount, и компилятор и не почешется на эту тему, и останется только уповать на тесты.
Да. В итоге ты написал проверку неправильного кода для двух условий. Как только дело дошло до большего количества, как внезапно «там дальше все очевидно, метакласс, а ты тупой, не читаешь статью, что тебе там непонятно». Мне непонятно, почему, раз все так очевидно, ты так долго не можешь ответить на мою просьбу показать, как эта очевидность будет реализована
Ну и так далее и тому подобное. В общем, про это в соседней ветке Sinclair более грамотно написал.
M>>В том-то и дело, что именно не справился. Все представленное — это именно «вот эту задачу мы можем решить так, далее все очевидно». ARK>Ну так это "не стал делать", а не "не справился".
Давай не будем десадовские отмазки приводить. Именно что не справились. Никто. Тебе Синклер про это уже писал
Здравствуйте, Mamut, Вы писали:
ARK>>Ну так это "не стал делать", а не "не справился". M>Давай не будем десадовские отмазки приводить. Именно что не справились. Никто. Тебе Синклер про это уже писал
Ну, раз даже Синклер писал, то это все в корне меняет.
M>Вы предпочитаете теоретизировать, а как дело доходит до реальности — полтора незаконченных примера и пафос.
Я пишу скорее для других потенциальных читателей топика, чтобы у них не сложилось однобокое мнение о так называемых "теоретиках".
Именно это основная цель этого моего постинга (и предыдущего). Ругань в мои цели не входит, приношу извинения, если что-то задело.
M>>Вы предпочитаете теоретизировать, а как дело доходит до реальности — полтора незаконченных примера и пафос.
ARK>Лично я (за остальных не говорю) "предпочитаю" не писать длинные примеры из реальности, особенно когда собеседник не слишком настроен на конструктивную дискуссию,
Я настроен на конструктивную дискуссию
ARK>не слишком пытается понять, о чем речь, а требует, чтобы ему "доказали" (у меня сложилось именно такое впечатление, но, безусловно, каждый волен самостоятельно прочесть дискуссию и сделать собственные выводы).
Я в том-то и дело пытаюсь понять. Только вы не даете никаких возможностей понять. Рассказывать сказки на сотню форумных страниц и я могу
ARK>Тратить приличное время на продумывание и написание кода только для какого-то форумного спора, да еще и чтобы в ответ услышать "что-то как-то неубедительно, у нас и так все работает"? Не вижу смысла.
Да я уже понял, что пропоненты стат. типизации способны оперировать только задачами уровня hello, world
Я виноват, что ты, видимо, не настроен?
M>>Тебе не странно, что от пропонентов — только прельстивые речи и ноль практики? ARK>ИМХО, ход дискуссии не располагает к написанию развернутых примеров.
Пока что с ней никто, от слова вообще, не справился 
Да, тут не поможет никто, кроме сантехника 
