V2 - finally!

[back2dos]

So, uhm ... here we are. The 2nd attempt. Mostly just deprecation, with the following:

Breaking changes

1. new Future() and new Signal() both lead to suspendable signals/futures. I guess nobody relied on those, so we should be fine
2. new Promise expects the initializer to return a CallbackLink. Might upset JS people, but I really would prefer for things to be authored in a suspendable manner. Should haxe ever get overloading/partial functions/optional returns, I'd be fine with supporting non-suspendable initializers.
3. Public API has been reduced. SignalObject and FutureObject are private. This is to guarantee certain invariants. This happened to caused an edge case in tink_lang (resolved on HEAD), but I doubt anybody will be affected.
4. Futures are fully lazy (unless explicitly made eager or you're using deprecated APIs). This might bite you, although laziness was already gradually increased in tink_core v1.
5. The long time deprecated Future<Array<T>> @:from Array<Future<T>> cast is gone, as is Callback<T> @:from Callback<Noise>

Deprecations

1. Gathering is generally deprecated
2. Future.async is fully deprecated (but behaves as before in respect to lazyness), in favor of Future.irreversible and the more preferable new Future. Before my idea was to flip the behavior to default to lazy, but that seems like it's inviting a lot of trouble.
3. CallbackLink::dissolve is deprecated in favor of CallbackLink::cancel.
4. Future.ofMany is deprecated in favor of Future.inSequence.
5. deprecated >> for futures

Status

Tests pass (as tink_testrunner itself makes strong use of tink_core, that's a rather good sign). I also dropped this into MVCoconut/examples-todomvc and it works without issues. So all in all, it should be fine to use. You can expect quite a few deprecation warnings popping up in

Notable Additions

Lazy

• added var computed(get, never):Bool to check if a lazy is already computed
• protect Lazy against stackoverflow ... will not work if you nest Lazy.ofFunc indefinitely, but for nested .map / .flatMap it will do

Future

• Added inParallel / inSequence to match Promise
• Added var status(get, never):FutureStatus<T> which tells you a future's status. The most notable one is Ready(result:Lazy<T>) which allows processing sync (or resolved) futures in a sync manner. This should allow speeding things up in tink_streams (e.g. Recursiveness and php tink_streams#20)

Signal

• SignalTrigger can now be destroyed
• derived signals are destroyed when all their sources are destroyed

---

In any case, please let me know what you think and if you get any other regressions from this. I would like to merge this sooner rather than later, because it enables a few improvements in dependent libs.

[back2dos]

Oh, one more notable breaking change: Haxe 3 is no longer supported ^^

[kevinresol]

At first it is quite hard to understand what "suspendable" means, by just looking at the code. But after your explanation I understood it and found it really nice. I am happy to have it as default. Also we should document it.

[kevinresol]

btw will we deprecate Signal::handle and promote Signal::listen?

[back2dos]

btw will we deprecate Signal::handle and promote Signal::listen?

Hmm, we could, but TBH I never quite understood why ProgressObject had to be implemented as a direct subtype of FutureObject and SignalObject. Right now I made both private and ProgressObject is composed from Future and Signal, which seems to work just fine.

OTOH, if you're suggesting that having a different name might reduce confusion, I'd say that's a thought worth exploring :)

[kevinresol]

Hmm, we could, but TBH I never quite understood why ProgressObject had to be implemented as a direct subtype of FutureObject and SignalObject.

I don't know too. But now i can see composition is better.

[back2dos]

Ok, let's do this!

[grepsuzette]

Wow I had miss this was already released!
Think Disposable is also a notable addition, at least from a glance.
Congratz'