Thanks for the suggestion, I will certainly look into this.
My instinct to use promises was because we're primarily interested in
retrieving external resources, which is inevitably done by calling out to
Javascript APIs, and most of those APIs these days manage the asynchrony using
JavaScript promises.
Michael Kay
Saxonica
On 1 Aug 2020, at 04:08, Dimitre Novatchev <dnovatchev(_at_)gmail(_dot_)com>
wrote:
First of all, congratulations to the Balisage organizers for organizing this
conference even in the current situation.
I read Dr. Kay's paper "Asynchronous XSLT" from the proceedings of
Balisage-2020:
https://www.balisage.net/Proceedings/vol25/html/Kay01/BalisageVol25-Kay01.html
<https://www.balisage.net/Proceedings/vol25/html/Kay01/BalisageVol25-Kay01.html>
While the described new feature (promises) is impressive and will be a step
in the right direction, people who have used both promises and reactive
extensions (RxJs in particular, a Javascript implementation of Reactive
Extensions: http://reactivex.io <http://reactivex.io/languages.html> ) point
out certain advantages of using Rx observables over promises:
Promises produce only one event; Observables produce a stream of events.
Promises are not lazy; Observables do not fire even after being created, they
start emitting the event stream only upon subscription.
Working with nested and interdependent promises can be cumbersome and
unwieldy; Much easier and structured when expressed and handled with
observables.
Promises, once started, cannot be cancelled; Observables were designed having
cancellation in mind.
Shall we mention multicasting ...
Here is a brief video that shows this in running code:
https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises
<https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises>
The reason for my message is that it is still not too late to make an
informed design decision that takes into consideration the established best
approach towards implementing the handling of asynchrony in almost all major
programming languages, and, to have a written evidence that this problem had
at least been raised and (hopefully) discussed.
To quote http://reactivex.io/languages.html
<http://reactivex.io/languages.html> , Rx has been implemented in these
languages, platforms and frameworks:
Languages
Java: RxJava <https://github.com/ReactiveX/RxJava>
JavaScript: RxJS <https://github.com/ReactiveX/rxjs>
C#: Rx.NET <https://github.com/Reactive-Extensions/Rx.NET>
C#(Unity): UniRx <https://github.com/neuecc/UniRx>
Scala: RxScala <https://github.com/ReactiveX/RxScala>
Clojure: RxClojure <https://github.com/ReactiveX/RxClojure>
C++: RxCpp <https://github.com/Reactive-Extensions/RxCpp>
Lua: RxLua <https://github.com/bjornbytes/RxLua>
Ruby: Rx.rb <https://github.com/Reactive-Extensions/Rx.rb>
Python: RxPY <https://github.com/ReactiveX/RxPY>
Go: RxGo <https://github.com/ReactiveX/RxGo>
Groovy: RxGroovy <https://github.com/ReactiveX/RxGroovy>
JRuby: RxJRuby <https://github.com/ReactiveX/RxJRuby>
Kotlin: RxKotlin <https://github.com/ReactiveX/RxKotlin>
Swift: RxSwift <https://github.com/kzaher/RxSwift>
PHP: RxPHP <https://github.com/ReactiveX/RxPHP>
Elixir: reaxive <https://github.com/alfert/reaxive>
Dart: RxDart <https://github.com/ReactiveX/rxdart>
ReactiveX for platforms and frameworks
RxNetty <https://github.com/ReactiveX/RxNetty>
RxAndroid <https://github.com/ReactiveX/RxAndroid>
RxCocoa <https://github.com/kzaher/RxSwift>
.
Why don't we make XSLT part of this large family, where all developers
already know, use and understand the functions and operators, and will be
able with minimum effort to also use the same in XPath/XSLT?
Or is this really challenging because of existing inherent problems in XSLT?
--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what you're
doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
all patents, too? :)
-------------------------------------
Sanity is madness put to good use.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--