Re: Ada-Oriented GUI

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

On 24/03/18 14:12, Dmitry A. Kazakov wrote:
> On 2018-03-24 12:36, Alejandro R. Mosteo wrote:
> 
>> Rx Observer contract:
>>
>> OnNext* (OnCompleted | OnError)?
>>
>> Events arrive once, thread-safely (OnNext call). End of sequences is 
>> notified once with success or failure, so cleanup is trivial.
> 
> Well, how is that triviality any new or groundbreaking? The interfaces I 
> have in Simple Components for communication protocols are just like this.

I'd say, more than groundbreaking, is a neat tool that fulfills a need 
and that has reached critical mass, so that you can find lots of 
resources and practitioners.

>> The emitter of events is an Observable. The consumer is an Observer. 
>> Combinations of both are Operators. There are many predefined Operators 
>> to make life easy, addressing most needs that would be otherwise 
>> complex (e.g. tasking ones).
> 
> Since I am using this model too, this is by no means any better than 
> other methods. In fact it is far worse! The reason why I am using it is 
> because there is no other way dealing with asynchronous I/O under the 
> constraint of limited number of tasks. The implementations of all 
> protocols in Simple Components are asynchronous.

I'll take a look.

> Now, programming this is like scratching your left ear with the right 
> hand. I keep on asking for co-routines in Ada to break out of this lousy 
> awful mess. To rein assorted mess of events/callbacks into a sequence 
> imperative calls to be a able to program it as if it were an 
> uninterrupted thread of control maintaining its state, just like if the 
> I/O were synchronous.

I've never used coroutines. Since this kind of "imperative-like" 
sequences is what Rx provides, I understand that coroutines will allow 
the same without staying in the declarative realm?

There are AIs for generators in Ada, maybe these will be among the chosen 
ones?

>> For my own specification package: https://goo.gl/WQfpeV
> 
> Good work, BTW.

Thanks!

Álex.

> 
> [...]
> 
>> Since you asked about TreeViews elsewhere, I see they somehow do it 
>> (but don't ask me how. It's probably ugly JS):
>> https://react.rocks/tag/TreeView
> 
> Too simple to judge. Usually problems start with columns, rendering nodes 
> differently depending on conditions, evaluation of the three dimensions etc.
> 
>>> [There is nothing simple or elegant in event-controlled architectures. 
>>> Doing this for 20+ years (this is state of the art in automation 
>>> systems), I am pretty sure of.]
>>
>> The most elegant designs can turn ugly once things get real, that's for 
>> sure...
> 
> No. This is another set properties: scalability, composability.
>