Problem
There might be some situations in the future where it would be useful to be able to have the various chelonia/ selectors operate on different CheloniaContext objects.
At this time it's unclear what those scenarios might be. In case it becomes necessary, however, we did discuss how to approach this in a way that involves minimal breaking changes. See the solution below:
Solution
This would introduce a new function, implemented either in this library, or in @sbp/sbp itself, called sbpC. This function would behave exactly like the sbp selector, with the exception that it would take a leading parameter that would rebind this to that first parameter (instead of the default global selector context that's currently used).
Then libchelonia would be updated to use this selector, and we would have to make 100% sure that all invocations of any Chelonia selectors used this function instead of sbp. This is to ensure consistency in the value of this when one Chelonia selector calls another Chelonia selector (for example, 'chelonia/contract/sync' calling 'chelonia/private/out/sync' which in turns calls 'chelonia/private/in/syncContract' via 'chelonia/private/queueEvent' which in turn calls 'chelonia/private/in/handleEvent' which calls sbp(this.config.stateSelector) etc. etc.
That entire chain of chelonia/ namespaced selectors needs to use the correct consistent this binding, and to ensure that happens all sbp calls would need to be replaced with sbpC calls to pass the currently-bound this down the line.
We could also make it so that sbpC is itself defined as a key of the CheloniaContext, so that you wouldn't have to pass in this as the first parameter. Instead, you'd call it like so: this.sbpC.
Then we'd also have to transform chelonia/_init into more of an explicitly called constructor that was publicly exposed so that callers could generate new CheloniaContext objects, and perhaps merge it with chelonia/configure so that allocation and initialization happened in a single call rather than two.
And finally we'd expose the sbpC function publicly so that whenever someone wanted to use Chelonia selectors with custom contexts they'd use that function to call the selectors.
Problem
There might be some situations in the future where it would be useful to be able to have the various
chelonia/selectors operate on differentCheloniaContextobjects.At this time it's unclear what those scenarios might be. In case it becomes necessary, however, we did discuss how to approach this in a way that involves minimal breaking changes. See the solution below:
Solution
This would introduce a new function, implemented either in this library, or in
@sbp/sbpitself, calledsbpC. This function would behave exactly like thesbpselector, with the exception that it would take a leading parameter that would rebindthisto that first parameter (instead of the default global selector context that's currently used).Then libchelonia would be updated to use this selector, and we would have to make 100% sure that all invocations of any Chelonia selectors used this function instead of
sbp. This is to ensure consistency in the value ofthiswhen one Chelonia selector calls another Chelonia selector (for example,'chelonia/contract/sync'calling'chelonia/private/out/sync'which in turns calls'chelonia/private/in/syncContract'via'chelonia/private/queueEvent'which in turn calls'chelonia/private/in/handleEvent'which callssbp(this.config.stateSelector)etc. etc.That entire chain of
chelonia/namespaced selectors needs to use the correct consistentthisbinding, and to ensure that happens allsbpcalls would need to be replaced withsbpCcalls to pass the currently-boundthisdown the line.We could also make it so that
sbpCis itself defined as a key of theCheloniaContext, so that you wouldn't have to pass inthisas the first parameter. Instead, you'd call it like so:this.sbpC.Then we'd also have to transform
chelonia/_initinto more of an explicitly called constructor that was publicly exposed so that callers could generate newCheloniaContextobjects, and perhaps merge it withchelonia/configureso that allocation and initialization happened in a single call rather than two.And finally we'd expose the
sbpCfunction publicly so that whenever someone wanted to use Chelonia selectors with custom contexts they'd use that function to call the selectors.