Open lorents opened 3 years ago
Status update:
My motivation for introducing rtl::set<T>
was to build an observable vector on top of it, thinking this was a good stepping stone towards that. However, during a moment of clarity i managed to implement the observable vector on its own (dubbed rtl::vec<T>
).
Turns out we didn't even need the rtl::populator
at all, instead there is a reactive rtl::vec<T>::poll(rtl::iterator)
method that gives you the list events since the last time it was called with that iterator instance; so you just call poll()
inside a regular rtl::animator
and do something with the insert/remove events you get back from that.
I plan to push this as soon as i have some more tests for it, but it seems to work.
I have implemented map()
, fmap()
and filter()
for this vec<T>
, but the functions passed to those are not reactive. E.g. if the result of the condition passed to filter()
changes, the vector would not change, which is a bummer (but good for memory usage if you don't need that). There will be corresponding rmap()
, rfilter()
and rfmap()
methods though that actually change the list if a dependency of the function passed to them changes.
rtl::set<T>
would be an observable set, with operators like|
&
^
-
rtl::populator
would be a sibling ofrtl::animator
where each new element is transformed into a collectable resource which is collected when removed.There is also no reason not to support modifying sets that are already collections. this will behave like a modifier on the previous value.
would really be the same as
Further,
rtl::populator
would make sense to work withrtl::var<T>
too, behaving like a list with a single element