Browse thread
Recursion on React.events.
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2009-12-10 (03:38) |
From: | Daniel_Bünzli <daniel.buenzli@e...> |
Subject: | Re: [Caml-list] Re: Recursion on React.events. |
> Unfortunately, it seems to me that Daniel's module is fairly low-level in > the sense that it implements the bare mechanics and semantics of FRP. Yes, react is low-level and will remain. The rationale is that I want the client of the module to be able to decide the application structure. This makes react more flexible and easier to embed were you need to. I could have decided that react has a global queue and every primitive update has to go through that queue (for the client this would have simplified the feedback of primitives into the reactive system). But then the module is not thread-safe and you get compositional problems when you want to integrate two libraries using react in a threaded environment. I could have decided that the reactive engine runs on its own thread but maybe you don't want to use threads etc. For example with the current design two part of a program may use react as they wish internally without any problem even on different threads as long as their signals and events don't interact. With the current structure it also means that a library designer using react has to make sure the way he design should play nice with other part defining their own primitive events. So yes it means a little bit more work and understanding for the client. But I think it pays to have a reactive engine that doesn't impose too much on you. The client always knows better the abstraction he's after and the setting in which it has to implement it. But if a consistent and compositional pattern of use emerges I'm always willing to support it directly in the library. > For example, make a parser of the Asterisk Manager Interface > with React around OCamlNet's Uq_engine module proved to be quite tricky, in > a similar way as the issue that started this thread (here, I had no event, > but in the Asterisk parser, I had doubled events, and I solved it in a very > very ugly way). Note that as we discussed I highly suspect you used the wrong abstraction there (events vs. signals). > It's true that I may not completely understand how React works, as Daniel stated it before (a bit better now) Btw this was not intended to be offensive. It was to say the reactive engine has a well defined way to work that should be respected (the update cycle) so don't try to trick around too much with it when you cannot achieve want you want. Best, Daniel