Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V2 - finally! #123

Merged
merged 98 commits into from
Jun 12, 2020
Merged

V2 - finally! #123

merged 98 commits into from
Jun 12, 2020

Conversation

back2dos
Copy link
Member

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
Copy link
Member Author

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

@skial skial mentioned this pull request Jun 11, 2020
1 task
@kevinresol
Copy link
Member

kevinresol commented Jun 11, 2020

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
Copy link
Member

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

@back2dos
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

Ok, let's do this!

@back2dos back2dos merged commit b0b9879 into master Jun 12, 2020
@back2dos back2dos deleted the v2_again branch June 12, 2020 11:47
@grepsuzette
Copy link

grepsuzette commented Jun 28, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants