Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event-and-Behavior boilerplate #177

Open
mitchellwrosen opened this issue May 27, 2018 · 1 comment
Open

Event-and-Behavior boilerplate #177

mitchellwrosen opened this issue May 27, 2018 · 1 comment

Comments

@mitchellwrosen
Copy link
Collaborator

I often write this somewhat boilerplatey definition of a Behavior:

eFoo <- accumE x eUpdate
bFoo <- stepper x eFoo

This is typical, because at times I want to sample a behavior, and at other times I want to express something in terms of the events that update it.

It's unsatisfactory because:

  • I have to manually make sure that I pass in the same initial value x
  • The event and behavior are "linked" by name alone, but they are very related to each other.

I've read the documentation to changes multiple times, and I think I understand the appeal to the semantics of a behavior as a time-varying value with no concept of a discrete step from one value to another.

However, in code as above, it feels like I have a little backdoor to these semantics. All I've done is manually roll my own accumB and suddenly I do have a handle on the discrete steps that the behavior undergoes.

Given this, I'm a little unsure of why Behavior takes care to throw away the underlying Pulse a of updates in favor of a Pulse () that fires at the same time.

I'm curious to know what (whoever's listening's) thoughts are on this, and about the Dynamic type from reflex, which seems to attempt to solve this problem by just paring up a Behavior with an Event that carries its updates. reactive-banana notably doesn't have this convenience type; is it to keep the API simple, or because it is an odd type semantically, or something else?

Thanks =)

@HeinrichApfelmus
Copy link
Owner

HeinrichApfelmus commented May 11, 2019

The benefit of having a Behavior type where you can not get the changes is that any code using this code is guaranteed to be independent of the frequency of ("spurious") changes. For example, if you consider a slightly different event and behavior,

eFoo' <- accumE x $ unionWith (.) eUpdate (id <$ eSomeOtherEvent)
bFoo' <- stepper x eFoo'

then the behaviors bFoo' are bFoo are nonetheless semantically equal, even though they arise from accumulations of events that not equal.

In practice, I found a Tidings type more useful than Dynamic. The key difference is that the values contained in the rumors need not occur in the facts at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants