Должны ли события быть внешне изменяемыми? - PullRequest
4 голосов
/ 18 января 2012

Я играю с FRP, и мне было интересно, как акт «происходящего» события должен рассматриваться публично. Под этим я подразумеваю, должен ли программист выполнять следующие действия в контексте FRP:

event.occur(now, 5)

Я никогда не видел примеров этого ни в одной из статей FRP, и мне это не кажется правильным. Я чувствую, что платформы FRP должны действительно скрывать этот тип действия, и что события должны происходить только за сценой. Правильно ли я думаю об этом?

Чтобы уточнить, мой подход состоял бы в том, чтобы «происходит» только для самого класса Event. Если требуется абстракция для какого-либо внешнего источника (например, мыши), его можно построить, расширив класс Event. Таким образом, вся логика, связанная с созданием возникновения, абстрагируется.

1 Ответ

6 голосов
/ 18 января 2012

Хорошо, если библиотека FRP предоставляет способ связывания с внешними событиями - например, существующей структурой, основанной на событиях, - тогда она должна обеспечивать эквивалентную функциональность или не может взаимодействовать с внешней средой.world.

Однако вопрос на самом деле: что вы подразумеваете под «внешним»?Сама система FRP обычно считается чистой, поэтому идея выполнения побочного кода, такого как event.occur(now, 5), внутри системы FRP даже не имеет смысла.Обычно, конечно, средство для выполнения такого кода в ответ на события FRP предоставляется , но это обычно принимается не как часть чистой модели программирования, а как средство для взаимодействия сети в целомс внешним миром.

Итак, по моему мнению, есть два возможных способа интерпретации этого вопроса:

  1. Если возможно вызвать событие извнеСистема FRP? - безусловно, да, поскольку она необходима для взаимодействия с внешним миром, но это не влияет на модель программирования самого FRP.
  2. Должна ли быть возможность инициировать событие из«внутри» системы FRP, предполагая, что имеется возможность для выполнения побочного кода в ответ на событие? - также да, потому что разрешено нормальному побочному коду вызывать события, но запрещается его внутри кода, выполняемого в ответ насобытия кажутся очень странным (и обходимым) ограничением, учитывая, что намерениеy должен взаимодействовать с внешним миром.

Действительно, возможно вызвать что-то подобное # 2, даже если вы явно запретите это: рассмотрите возможность настройки, чтобы switchToWindow 3 выполнялось, когда событиеbuttonClicked триггеры, например (с использованием реактивный банан нотация):

reactimate (switchToWindow 3 <$ buttonClicked)

И скажем, что у нас есть событие

newWindowFocused :: Event Int

Реакция, которую мы имеемустановка вызывает событие newWindowFocused, даже если события запуска изнутри кода, выполняемого из-за события, предотвращаются.

Теперь все, что я сказал до сих пор, касается только «внешних» событий: это невыражается в чистом FRP, но явно создан для представления событий, происходящих во внешнем мире, за пределами системы FRP.Если вы спрашиваете, должна ли быть возможность вызывать особые события в чисто определенных событиях, тогда мой ответ: абсолютно нет!Это разрушает смысл системы, потому что внезапно fmap f (union e1 e2) не означает "происходит со значением f x, когда e1 или e2 происходит со значением x", а вместо этого "происходит со значением f xкогда e1 или e2 происходит со значением x ... или когда какой-то внешний код случайным образом решает его запустить ".

Мало того, что такое средство будет рассуждать о поведении FRPсистема по сути бессмысленна, 1 это также нарушит ссылочную прозрачность: если вы создадите два события, эквивалентных fmap f (union e1 e2), вы можете различить их, запустив одно и заметив, что другое не происходит.Вы просто не можете предотвратить это во всех случаях: представьте fmap g (union e1 e2), где f вычисляет ту же функцию, что и g;равенство в функциях не решаемо:)

Конечно, вполне возможно реализовать FRP на нечистом языке, но я думаю, что предоставление способа нарушить ссылочную прозрачность самой системы FRP - очень плохая вещь,в конце концов, это чистая модель.

ЕслиЯ правильно понимаю, что ваше решение этого недостатка в API (а именно, публичное разоблачение occur, что нарушает ссылочную прозрачность эквивалентных событий и т. Д., Как я говорил выше) было бы сделать occur внутренним по отношению к вашему Event класс, чтобы его нельзя было использовать снаружи.Я согласен, что если вам нужно occur внутри, это правильное решение.Я также согласен с тем, что разумно представить его подклассам, если ваша реализация внешних событий выполняется с помощью подкласса Event.Это подпадает под «клей внешнего мира», который выходит за рамки самой модели FRP, поэтому вполне нормально дать ему возможность «нарушать правила» таким образом - в конце концов, это по сути то, что для : нарушение системы с побочными эффектами:)

Итак, в заключение:

Нет, события не должны подвергать этот интерфейс.

Да, Вы правы, думая так:)

1 Конечно, вы можете утверждать, что внешние события делают это полная остановка ,поскольку в целом поведение системы в конечном итоге зависит от «ребер», подключенных к внешнему миру, но это не совсем так: да, вы не можете ничего предположить о внешних событиях самих ,но вы все еще можете положиться на все, что вы строите из них, чтобы подчиняться законам их конструкций.Предоставление возможности «внешнего обжига» каждому событию означает, что ни у одного строительства нет никаких законов.

...