Thursday, December 22, 2016

CwlSignal and Reactive Programming

Matt Gallagher:

The careful separation of “input” and “output” and the modelling of reactive programming as a channel is a distinguishing feature of CwlSignal. Other common implementations treat reactive programming as an implementation of the “Observer” pattern but this leads them to hide the input end of their channels or confusingly use types that are both input and output, when only an input interface is desired.

[…]

Unlike functional programming inspired transformation functions (e.g. map, flatMap), the fundamental transform in CwlSignal does not return its result but sends it into the SignalNext (interface equivalent to SignalInput for sending to the next Signal in the chain). This design allows you to emit any number of values or an error.

Matt Gallagher:

In this article, I’ll explain why I consider reactive programming to be one of the most important design patterns for application programming by looking at three scenarios that are common in application development, yet are a drain on development time, lead to frequent bugs and make design and refactoring hard. I’ll show how reactive programming addresses the verbosity, eliminates the unsafety and restructures the code to aid maintainability.

[…]

The biggest advantage comes when you realize that in applying a solution to just one of these problems, you’ve gained a solution to the other three for free.

1 Comment RSS · Twitter


[…] CwlSignal and Reactive Programming […]

Leave a Comment