反应性香蕉的行为
请原谅,我刚刚开始研究反应香蕉和玻璃钢。
反应式香蕉的作者做了这个示例我的建议是,他创建一个可以增加和减少的计数器。他使用accumE函数来累积事件。我想我能够对事件类型有所了解,并且能够用它测试很多东西,但后来我想起还有行为。我调查了它,但似乎该行为应该在类似的情况下使用;修改现有变量,就像 AccumE 对事件所做的那样。
行为是什么意思,它的用例是什么?
Pardon me, I'm just starting to look into reactive-banana and FRP.
The author of reactive-banana made this example per my suggestion, in which he creates a counter which can be increased and decreased. He uses accumE function which accumulates events. I think I was able to somewhat grok the Event type, and was able to test quite a few things with it, but then I remembered that there was also Behavior. I looked into it, but it seems like the behavior is meant to be used in similar situations; to modify an existing variable, just like accumE does with events.
What does Behavior mean, and what are the use cases for it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我同意 Ankur 而不是 Chris 的观点:文本框是随着时间的推移而产生的值,因此自然希望成为一种行为而不是事件。 Chris 给出的事件选择不太自然的原因是实现问题,因此(如果准确的话)是反应式香蕉实现的不幸的产物。我更愿意看到实现的改进,而不是不自然地使用范例。
除了语义匹配之外,选择行为而不是事件在实用上也非常有用。例如,您可以使用
Applicative
操作(例如liftA2
)将随时间变化的文本框值与其他随时间变化的值(行为)组合起来。I agree with Ankur rather than Chris: a text box is a value over time and so naturally wants to be a behavior rather than an event. The reasons Chris give for the less natural choice of event are implementation issues and so (if accurate) an unfortunate artifact of the reactive-banana implementation. I'd much rather see the implementation improved than the paradigm used unnaturally.
Besides the semantic fit, it's pragmatically very useful to choose
Behavior
overEvent
. You can then, for instance, use theApplicative
operations (e.g.,liftA2
) to combine the time-varying text box value with other time-varying values (behaviors).从语义上讲,您有
即,
行为 a
是随时间变化的a
类型的值。一般来说,您对Behavior a
何时会发生改变一无所知,因此事实证明,通过点击 a 来更新文本字段是一个相当糟糕的选择。按钮。也就是说,很容易得到一个表示计数器示例中数字的当前值的行为。只需在事件流上使用stepper
,或者以相同的方式从头开始构建它,只不过使用accumB
而不是accumE
。通常,连接到输入和输出的事物始终是
Event
,因此Behavior
在内部用于中间结果。假设在给定的示例中,您想要添加一个记住当前值的新按钮,就像简单计算器上的记忆功能一样。您将首先添加一个记忆按钮和一个用于记住值的文本字段:
您需要能够随时询问当前值,因此在您的网络中,您需要添加一个行为来表示它。
然后,您可以连接事件,并在每次按下“记住”按钮时使用
apply
读取行为的值,并使用该值序列生成一个事件。最后,将这个新事件连接到输出
如果您想在内部使用内存,那么您也需要为其当前值提供一个行为......但因为我们只使用它来将其连接到输出,我们现在只需要一个事件。
这有帮助吗?
Semantically, you have
That is, a
Behavior a
is a value of typea
that varies over time. In general, you know nothing at all about when aBehavior a
would change, so it turns out to be a rather poor choice for updating a text field on the click of a button. That said, it would be easy to get a behavior that expresses the current value of the number in the counter example. Just usestepper
on the event stream, or alternatively, build it from scratch the same way, except by usingaccumB
instead ofaccumE
.Typically, things you hook up to input and output will always be
Event
s, soBehavior
is used internally for intermediate results.Suppose that in the given example, you want to add a new button that remembers the current value, like the memory function on simple calculators. You would start out by adding a memory button and a text field for the remembered value:
You need to be able to ask for the current value at any time, so in your network, you'd add a behavior to represent it.
Then you can hook up events, and use
apply
to read the value of the behavior every time the Remember button is pressed, and produce an Event with that sequence of values.And finally, hook up this new event to the output
If you wanted to use memory internally, then again you'd want a
Behavior
for its current value too... but since we only ever use it to connect it to an output, we only need an event for now.Does that help?
图书馆作者讲话。 :-)
显然,Chris Smith 可以读懂人心,因为他准确地描述了我的想法我在想。 :-)
但是 Conal 和 亚瑟也有道理。从概念上讲,计数器是一个随时间变化的值,而不是事件发生的序列。因此,将其视为一种
行为
会更合适。不幸的是,行为没有附带任何有关何时改变的信息,它们是“仅限民意调查”的。现在,我可以尝试实现各种巧妙的方案,最大限度地减少轮询,从而实现 GUI 元素的高效更新。 (Conal 在原始论文中做了类似的事情。)但我采用了“没有魔法”的哲学:库用户应负责自己通过事件管理更新。
我目前设想的解决方案是提供除了
Event
和Behavior
之外的第三种类型,即Reactive
(名称取决于变化),它体现了两者的品质:从概念上讲,它是一个随时间变化的值,但它也带有一个通知变化的事件。一种可能的实现是:毫不奇怪,这正是
sink
所期望的类型。这将包含在reactive-banana 库的未来版本中。编辑:我已经发布了reactive-banana 版本0.4 其中包括新类型,现在称为
Discrete
。Library author speaking. :-)
Apparently, Chris Smith can read minds because he accurately describes what I am thinking. :-)
But Conal and Arthur have a point, too. Conceptually, the counter is a value that varies in time, not a sequence of event occurrences. Thus, thinking of it as a
Behavior
would be more appropriate.Unfortunately, behaviors do not come with any information about when they will change, the are "poll-only". Now, I could try to implement various clever schemes that will minimize the polling and thus allow effient updates of GUI elements. (Conal does something similar in the original paper.) But I have adopted a "no magic" philosophy: the library user shall be responsible for managing updates via events himself.
The solution I currently envision is to provide a third type besides
Event
andBehavior
, namelyReactive
(name subject to change) which embodies qualities of both: conceptually, it's a value that varies in time, but it also comes with an event that notifies of changes. One possible implementation would beIt is no surprise that this is precisely the type that
sink
expects. This will be included in a future version of the reactive-banana library.EDIT: I have released reactive-banana version 0.4 which includes the new type, which is now called
Discrete
.一般来说,行为是在一段时间内发生变化的值。它是一个连续值,而事件是离散值。对于行为,值始终存在。
例如:文本框中的文本是一种行为,因为文本可以在一段时间内发生变化,但会有一个当前值,而作为事件中的键盘笔划,您无法查询键盘笔划的“当前”值价值。
Generally, Behavior is a value that changes over a period of time. It is a continuous value, where as events are discrete values. In case of Behavior a value is always present.
For example: The text on a text box is a Behavior as the text can change over a period of time but there will be a current value, where as a keyboard stroke in a event as you cannot query a keyboard stroke for its "current" value.