Currently, in Vinum, all systems are modelled around the idea that computations are instant- this makes that working with yielding code (or API, which a lot of Roblox's APIs are!) is entirely limited, as you have to use Observes, completely removing most if not all benefits that you used Vinum for.
The solution in my mind to support yielding code, is to introduce the idea of "progressive state". The idea is that a Calc-like object that any updates to it will launch in a different task/thread, and its calculator is equipped with a special type of injectors that allows to update the said object.
Consider this:
local deltaTime = Wrap(RunService.Heartbeat, 1, 0)
local progressor = Progress(1, function(use, become) -- the first argument is the inital state
local counter = 1
while counter < 10 do
local delta = read(deltaTime)
counter += delta
become(delta)
task.wait(delta)
end
end)
print(read(progressor)) -- 1.342343434 etc
In a real-world use case, you might make a progress bar by calling become after every time something is done (ie. loading bars)
Currently, in Vinum, all systems are modelled around the idea that computations are instant- this makes that working with yielding code (or API, which a lot of Roblox's APIs are!) is entirely limited, as you have to use
Observes
, completely removing most if not all benefits that you used Vinum for.The solution in my mind to support yielding code, is to introduce the idea of "progressive state". The idea is that a Calc-like object that any updates to it will launch in a different task/thread, and its calculator is equipped with a special type of injectors that allows to update the said object.
Consider this:
In a real-world use case, you might make a progress bar by calling
become
after every time something is done (ie. loading bars)