Вопрос не в холиварах, а в том, чтобы сравнить разные подходы.
У меня получилось в одну строчку. И я считаю это нагляднее и проще.
Что получится на php?
согласен, что дело в технологиях, а языки — лишь инструменты.
можно и на асемблере написать ООП.
вопрос в том, насколько естественно поддерживает язык какую-либо технологию.
в качестве продолжения :) этого коммента я написал в апдейте поста иллюстрацию на scheme, использующую нативное использование продолжения в форме call/cc.
уровень условности реализации, думаю, ясен.
попробуйте переписать аналогичное на PHP с сериализацией объекта.
ну просто для сравнения.
ответ в моём профиле — «мне нравится моя работа» :)
несмотря на ужасы, которое может нарисовать воображение по прочтении этой статьи — работа меня не очень напрягает (в том числе и потому, что конторка относительно «мелкая»).
это даёт мне возможность развиваться в других направлениях.
да. тут есть тонкость, которая затронутав комменте выше.
stateless — это протокол.
в принципе, выражение в статье «RESTful (statles)» не совсем предполагает синонимичность.
если не путаю, по принципам REST состояние приложения абстрагируется как «ресурс» (идентифицируемый URI, потомучто там всё ресурс.
в этом свете, «продолжения» — какраз и есть такой ресурс.
статью сейчас покурю. спасибо.
P.S.
слово «континуации» я скалькировал для придания ему большего оттенка терминологичности.
слово «продолжение» в контексте, не предполагающем понимания этого понятия, будет выглядеть немного неопределённо.
протокол — да.
но это вовсе не значит, что и приложение должно быть stateless.
если на пальцах:
мы с вами сейчас общаемся тоже по stateless протоколу.
коммент прочитан/коммент написан, и всё.
(сами комменты — это не внутреннее состояние, а его проявления.)
но это не мешает мне отвечать даже в нескольких цепочках.
хотя нет. таки мешает. я не могу ответить одним комментом на несколько сразу и приходится использовать ссылки типа «см. коммент выше» :)
да вот так, по большому счёту, если смотреть с позиции «сессия как состояние» — тут вообще ничо сложного нет — сериализовать вообще весь контекст приложения, и дело с концом.
вопрос в том, как это встраивается в язык программирования.
ну да, естественно, продложения более мощные конструкции.
однако yield всёже обладает некоторыми подходящими свойствами.
хотя я слабо представляю как можно их сделать на «обычных сях».
и интересно посмотреть как оно будет реализовано на PyPy.
но как её применить в этих случаях:
1. юзер нажимает кнопку «back» несколько раз и перепостит форму, которая уже была засубмичена
2. а потом нажимает кнопку вперёд, пропуская одну из форм.
3. юзер делает несколько копий первой формы, и продвигается паралельно по нескольким путям.
в случае с континуациями, восстанавливающимися по параметрам запроса, (спрятанным в форму):
1. приложение возвращается в предыдущее состояние
2. приложение возвращается в следующее состояние, как оно зафиксирвоано в форме
3. приложение двигается параллельными путями, как если бы это были разные юзеры
в случае с континуациями, восстанавливающимися из сессии (всегда последнее для любого запроса):
1. приложение посылает пользователя нафик
2. приложение посылает пользователя нафик
3. приложение посылает пользователя нафик
:))
континуации, в принципе, позволяют реализовать конечный автомат в пределах одной функции. но это одно из применений. (в другой терминологии — «сопрограмма с самой собой»).
но автомат подразумевает набор состояний и набор переходов между ними.
континуации сами по себе это не предполагают. они предполагают только «возврат».
автоматы это всётаки перпендикулярный подход.
в частности, эти подходы никак не пересекаются если подумать о недетерминированных автоматах с нечётким состоянием, котрые на континуациях ну никак не вписываются.
У меня получилось в одну строчку. И я считаю это нагляднее и проще.
Что получится на php?
а концепт сам по себе не очень определённый — это и действие, и результат действия, и результат как незадействованный результат действия :)
можно и на асемблере написать ООП.
вопрос в том, насколько естественно поддерживает язык какую-либо технологию.
в качестве продолжения :) этого коммента я написал в апдейте поста иллюстрацию на scheme, использующую нативное использование продолжения в форме call/cc.
уровень условности реализации, думаю, ясен.
попробуйте переписать аналогичное на PHP с сериализацией объекта.
ну просто для сравнения.
я а слабо представляю иную ситуацию.
несмотря на ужасы, которое может нарисовать воображение по прочтении этой статьи — работа меня не очень напрягает (в том числе и потому, что конторка относительно «мелкая»).
это даёт мне возможность развиваться в других направлениях.
stateless — это протокол.
в принципе, выражение в статье «RESTful (statles)» не совсем предполагает синонимичность.
если не путаю, по принципам REST состояние приложения абстрагируется как «ресурс» (идентифицируемый URI, потомучто там всё ресурс.
в этом свете, «продолжения» — какраз и есть такой ресурс.
статью сейчас покурю. спасибо.
P.S.
слово «континуации» я скалькировал для придания ему большего оттенка терминологичности.
слово «продолжение» в контексте, не предполагающем понимания этого понятия, будет выглядеть немного неопределённо.
но это вовсе не значит, что и приложение должно быть stateless.
если на пальцах:
мы с вами сейчас общаемся тоже по stateless протоколу.
коммент прочитан/коммент написан, и всё.
(сами комменты — это не внутреннее состояние, а его проявления.)
но это не мешает мне отвечать даже в нескольких цепочках.
хотя нет. таки мешает. я не могу ответить одним комментом на несколько сразу и приходится использовать ссылки типа «см. коммент выше» :)
вопрос в том, как это встраивается в язык программирования.
но таки в продвинутых бейсиках была команда renum, и это было не критично.
а ситуация со вставными розетками возникала от силы три раза (и розетки были уже пронумерованы не по-бейсиковски)
такчто да. тут лопухнулся.
наверно, добавлю это в пост.
вродебы единственный язык, котрый поддерживает продлжения полностью — это scheme.
но пример на scheme в статье ломал бы мозг два раза а не один :)
где-то выше комментом кидал ссылку с эмулятором продолжений для php.
(фактически — сериализация объекта и сохранение его куда угодно)
а цель статьи и была дать информацию к размышлению :)
и в статье «Inverting back the inversion of control» — с картинками.
какраз про кнопку back. и возможные извращения с ней.
однако yield всёже обладает некоторыми подходящими свойствами.
хотя я слабо представляю как можно их сделать на «обычных сях».
и интересно посмотреть как оно будет реализовано на PyPy.
да и пост в общем-то не про питон :)
это уже случилось :)
и именно фактические затраты времени на перекладывание всех проводов меня убеждают в необходимости более строгого учёта :)
но как её применить в этих случаях:
1. юзер нажимает кнопку «back» несколько раз и перепостит форму, которая уже была засубмичена
2. а потом нажимает кнопку вперёд, пропуская одну из форм.
3. юзер делает несколько копий первой формы, и продвигается паралельно по нескольким путям.
в случае с континуациями, восстанавливающимися по параметрам запроса, (спрятанным в форму):
1. приложение возвращается в предыдущее состояние
2. приложение возвращается в следующее состояние, как оно зафиксирвоано в форме
3. приложение двигается параллельными путями, как если бы это были разные юзеры
в случае с континуациями, восстанавливающимися из сессии (всегда последнее для любого запроса):
1. приложение посылает пользователя нафик
2. приложение посылает пользователя нафик
3. приложение посылает пользователя нафик
:))
тоесть я почти сам себе и кабельщик :)
но автомат подразумевает набор состояний и набор переходов между ними.
континуации сами по себе это не предполагают. они предполагают только «возврат».
автоматы это всётаки перпендикулярный подход.
в частности, эти подходы никак не пересекаются если подумать о недетерминированных автоматах с нечётким состоянием, котрые на континуациях ну никак не вписываются.
я там даже коммент оставил.