Where can I find the documentation or the example for promises?
Regards,
]an
-
- VIP Member
- Posts: 73
- Joined: 17 Oct 2006 5:49
-
- VIP Member
- Posts: 1466
- Joined: 28 Feb 2000 0:01
Futures and promises are new things in our world. The examples are to be found in the webSocket parts of the in the webService example program (IDE: Help -> Install Examples...). You can read a little about it and futures in WebSocket futures.
Regards Thomas Linder Puls
PDC
PDC
-
- VIP Member
- Posts: 83
- Joined: 6 Mar 2000 0:01
OK The keyword webservice is all I needed.
I must say that I just got my arms around promises and observables in Angular and was looking for the equivalents in VP 8.
Can anybody tell me if futures are the equivalent of observables? Can you 'subscribe' to futures?
I think this is all exiting new stuff!
I must say that I just got my arms around promises and observables in Angular and was looking for the equivalents in VP 8.
Can anybody tell me if futures are the equivalent of observables? Can you 'subscribe' to futures?
I think this is all exiting new stuff!

-
- VIP Member
- Posts: 1466
- Joined: 28 Feb 2000 0:01
No, futures are not equivalent to observables.
observables are related to "event streams".
futures and promises deal with single asynchronous operations.
If you consider the webSocket stuff then we offer a read operation, that can will perform one read operation which will complete some time in the future.
In a system with observables we would have implemented the read operations in a predesigned loop and you would then observe a stream of webSocket message events.
It seems that many people have faith in Reactive Extensions (ReactiveX).
=== Begin prejudice
===
I am however not convinced, because I think it seems to repeat a problem that has been seen before in other "event" contexts (for example SAX parsing of XML documents).
The problem arise when you somehow need to "merge" the results of several (semi-)independent event sources (i.e. observables).
As the simplest possible example let us simply imagine that that we have two event sources whose events will always match-up in pairs; you need one of each to create a "merge".
In synchronous code you could imagine this (oversimplified) loop:
S1 and S2 are the "event sources" (for example a webSocket).
Such a loop can without much problems made asynchronous using await and/or futures.
It is however quite difficult to attach observers to S1 and S2 which can perform such a merge. The observers are too independent of each other; and thus very difficult to "synchronize" with each other.
ReactiveX library have several kinds of operations that performs "merge/synchronize" operations. The loop above corresponds to a zip of the two event sources.
Consider this slight modification:
The code is still very simple and understandable: we combine two pieces of data from S1 with one from S2
I do not know how ReactiveX code corresponding to this looks like (if it exists), but I fear that it is not as easy and straightforward as the modification I made.
=== End prejudice ===
observables are related to "event streams".
futures and promises deal with single asynchronous operations.
If you consider the webSocket stuff then we offer a read operation, that can will perform one read operation which will complete some time in the future.
In a system with observables we would have implemented the read operations in a predesigned loop and you would then observe a stream of webSocket message events.
It seems that many people have faith in Reactive Extensions (ReactiveX).
=== Begin prejudice

I am however not convinced, because I think it seems to repeat a problem that has been seen before in other "event" contexts (for example SAX parsing of XML documents).
The problem arise when you somehow need to "merge" the results of several (semi-)independent event sources (i.e. observables).
As the simplest possible example let us simply imagine that that we have two event sources whose events will always match-up in pairs; you need one of each to create a "merge".
In synchronous code you could imagine this (oversimplified) loop:
Code: Select all
clauses
loop(S1, S2) :-
E1 = S1:read(),
E2 = S2:read(),
merge(E1, E2),
loop(S1, S2).
Such a loop can without much problems made asynchronous using await and/or futures.
It is however quite difficult to attach observers to S1 and S2 which can perform such a merge. The observers are too independent of each other; and thus very difficult to "synchronize" with each other.
ReactiveX library have several kinds of operations that performs "merge/synchronize" operations. The loop above corresponds to a zip of the two event sources.
Consider this slight modification:
Code: Select all
clauses
loop(S1, S2) :-
E1a = S1:read(),
E1b = S1:read(),
E2 = S2:read(),
merge(E1a, E1b, E2),
loop(S1, S2).
I do not know how ReactiveX code corresponding to this looks like (if it exists), but I fear that it is not as easy and straightforward as the modification I made.
=== End prejudice ===
Regards Thomas Linder Puls
PDC
PDC
-
- VIP Member
- Posts: 83
- Joined: 6 Mar 2000 0:01
Thanks Thomas!
The reactiveX library contains some 68 different operators on observables and your story illustrates why that large number would be necessary. A practical point is that the programmer needs to remember to unsubscribe from the observable when finished, otherwise the events will continue to consume memory behind the scene.
I like the (dot or :) chaining of operators. If you consider the object the operators act upon as a state and each operator adds to the state then operators down the line also have access to the intermediate results. But that is a matter of conventions.
Regards,
]an
The reactiveX library contains some 68 different operators on observables and your story illustrates why that large number would be necessary. A practical point is that the programmer needs to remember to unsubscribe from the observable when finished, otherwise the events will continue to consume memory behind the scene.
I like the (dot or :) chaining of operators. If you consider the object the operators act upon as a state and each operator adds to the state then operators down the line also have access to the intermediate results. But that is a matter of conventions.
Regards,
]an