In prerparing chronos for a v4 release with raise tracking and other mildly incompatible changes, it's a good opportunity to revisit some of the core types and definitions - this PR starts that journey by introducing chronos/futures which contains the Future type along with those usage helpers that don't require event loop / callSoon support.
This subset allows breaking cyclic dependencies in applications using chronos and makes it easier to integrate chronos into applications in general, by allowing them to use the Future type independently of the rest of the chronos library, for example to expose their API expectations in modules that don't import all of chronos (and thus keep symbol pollution down).
The full migration is expected to affect backwards compatiblity more significantly, thus a chronosv4 define can be used to "preview" the breaking changes - this set is expected to grow up to the v4 release, but the aim is to maintain a more or less complete v3 subset such that applications can target both v3 and v4 with relative ease for a transition period (similar to how chronosStrictExceptions was introduced).
This is the the first of a series of PR:s that gradually will introduce the new features.
introduce chronos/config that collects and documents compile-time configuration flags
initial code moves that introduce chronos/futures
simplify transformation code
prevent modification of internal Future fields by making most of them private (TODO currently breaking even in v3)
FutureState.Finished -> FutureState.Completed to stay consistent with function names
introduce low-level Future constructors that create "finished" futures (TODO naming - convenience of reusing completed vs template lookup conflicts due to overloading)
In prerparing chronos for a v4 release with raise tracking and other mildly incompatible changes, it's a good opportunity to revisit some of the core types and definitions - this PR starts that journey by introducing
chronos/futures
which contains theFuture
type along with those usage helpers that don't require event loop /callSoon
support.This subset allows breaking cyclic dependencies in applications using
chronos
and makes it easier to integratechronos
into applications in general, by allowing them to use theFuture
type independently of the rest of the chronos library, for example to expose their API expectations in modules that don't import all of chronos (and thus keep symbol pollution down).The full migration is expected to affect backwards compatiblity more significantly, thus a
chronosv4
define can be used to "preview" the breaking changes - this set is expected to grow up to the v4 release, but the aim is to maintain a more or less complete v3 subset such that applications can target both v3 and v4 with relative ease for a transition period (similar to howchronosStrictExceptions
was introduced).This is the the first of a series of PR:s that gradually will introduce the new features.
chronos/config
that collects and documents compile-time configuration flagschronos/futures
Future
fields by making most of them private (TODO currently breaking even in v3)FutureState.Finished
->FutureState.Completed
to stay consistent with function namesFuture
constructors that create "finished" futures (TODO naming - convenience of reusingcompleted
vs template lookup conflicts due to overloading)