Re: Musings on RxAda

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

Dmitry A. Kazakov wrote:

> On Thu, 22 Oct 2015 13:02:46 +0200, Alejandro R.  Mosteo wrote:
> 
>> Observable.fromClickEvents(SomeButton)
>>     .onWorkerThread()  -- To ensure we are not blocking the GUI thread
>>     .count(during => one_second) -- This could be any costly operation
>>     .onGuiThread()               -- Switch back to GUI thread
>>     .subscribe(count -> SomeTextLabel.setText(count));
> 
> This looks like a plain active object. On click you simply call its
> primitive operation Count, straight from the event handler. The
> implementation of Count calls a task-safe SetText which marshals back to
> the GUI messages loop. Basically, 2 source code lines.

It might be so in this particular made-up example. I guess many cases of 
observables and filters in the RX framework are indeed active objects.

> There is not much use in this anyway. In a real-life GUI it is far more
> complicated. When a detached asynchronous operation starts, you normally
> need to be able to indicate its progress, to be able to cancel it, have to
> deal with MVC mess etc. As an example see how GPS handles the "build"
> button clicks. A crude mechanism like Observable would not scale.

The GUI was an example, the methodology has no specific purpose. For me, the 
interest is in how such a thing (the RX framework) could be implemented in 
Ada resulting in similar effort and clarity for the user as in other 
languages.

Here's a real use example if you're interested:
http://techblog.netflix.com/2013/02/rxjava-netflix-api.html

It would take someone more proficient on the framework than me to discuss 
the MVC/scalability issue.

>> What I see interesting of this methodology is that it basically hides (in
>> theory, of course then you read about nightmare histories) the explicit
>> definition of tasks,
> 
> It does not if you have to specify tasks. Active object does.
> 
>> problems with race conditions and data integrity,
> 
> I don't see why and how. It is too low level to judge. Especially
> integrity, because you seem ignore GUI elements bound to the detached
> execution. A typical problem is when SomeTextLabel gets killed while your
> thing keeps on counting...

I've left out everything about unsubscribing and error management in my 
effort to keep things simple.

>> The power of the setup comes with the huge number of predefined operators
>> that exist in the library. It's the closer to "chaining blocks" in
>> something like Simulink I've experienced in code.
> 
> It is a poor analogy because Simulink is 100% synchronous. (We are using
> that to make real-time out of the simulated one. In a custom Simulink
> block we do "delay until", and here you are, all simulation gets blocked.)

I was referring to the user experience connecting blocks, not about the 
implementation of the blocks that Simulink uses. Sorry if I was unclear. The 
Lego Mindstorms graphical blocks language would be a similar experience. 
Perhaps Scratch too.