These are needed to stop the generator - otherwise it would generate new events or update its value forever (there is also a function paused: () => Boolean but its purpose is different).
But right now all the methods inherited from EventStream/Signal return only a standard signal which means that the user needs to hold a reference to the original generator somewhere, to eventually stop it. This is okay in many cases but in soome others the user might want to create a complex generator and it would make sense to split into steps chained by .map, .flatMap, etc., and then just keep a reference to the final signal.
For this I can extract these two methods into a trait, Closeable and then overwrite those methods. (They would need to lose their final keyword...)
I could even create CloseableStream and CloseableSignal, instead of overwriting directly in generator classes. After all, from the outside it's only important that the event stream / signal can be closed, not that it's a generator.
It would also be a step connecting generators and Finite streams and signals. They will be automatically closeable, but they can inherit and modify Closeable anyway ... or not. Something to think about.
On top of that, the Closeable trait could inherit from java.lang.AutoCloseable, so maybe I could in future use it in try-with-resources ?...
GeneratorStreamandGeneratorSignalhave methods:These are needed to stop the generator - otherwise it would generate new events or update its value forever (there is also a function
paused: () => Booleanbut its purpose is different). But right now all the methods inherited from EventStream/Signal return only a standard signal which means that the user needs to hold a reference to the original generator somewhere, to eventually stop it. This is okay in many cases but in soome others the user might want to create a complex generator and it would make sense to split into steps chained by.map,.flatMap, etc., and then just keep a reference to the final signal.For this I can extract these two methods into a trait,
Closeableand then overwrite those methods. (They would need to lose theirfinalkeyword...) I could even createCloseableStreamandCloseableSignal, instead of overwriting directly in generator classes. After all, from the outside it's only important that the event stream / signal can be closed, not that it's a generator. It would also be a step connecting generators andFinitestreams and signals. They will be automatically closeable, but they can inherit and modifyCloseableanyway ... or not. Something to think about. On top of that, theCloseabletrait could inherit fromjava.lang.AutoCloseable, so maybe I could in future use it in try-with-resources ?...