In preparing 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 chronosPreviewV4 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.
initial code moves that introduce chronos/futures
simplify transformation code
prevent modification of internal Future fields by making most of them private
FutureState.Finished -> FutureState.Completed to stay consistent with function names
introduce low-level Future constructors that create "finished" futures
public parts of the API that nonetheless are not part of the "stable" API are named "Internal"
arnetheduck
commented
1 year ago
In preparing 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/futureswhich contains theFuturetype along with those usage helpers that don't require event loop /callSoonsupport.This subset allows breaking cyclic dependencies in applications using
chronosand makes it easier to integratechronosinto applications in general, by allowing them to use theFuturetype 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
chronosPreviewV4define 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 howchronosStrictExceptionswas introduced).This is the the first of a series of PR:s that gradually will introduce the new features.
chronos/futuresFuturefields by making most of them privateFutureState.Finished->FutureState.Completedto stay consistent with function namesFutureconstructors that create "finished" futures