Updownquark
commented
8 years ago I mentioned in a later commit, it's not the safe methods that are breaking the tests. Tests are fixed on head. This is done unless I decide to rethink it. No testing on it yet though.
I've been thinking about how to make observables, and especially combinations involving observable collections, thread-safe. By which I mean that they only fire events on a single thread at a time, since firing on multiple threads at once could cause problems in listeners if they keep state. All the collection implementations are thread-safe, but the observable and observable value implementations and collection combinations (combine(), flatten(), refresh(), etc.) are not.
I was originally thinking to go through and thread-safe them all, but this might be overkill, since many applications will not need the thread-safety. So I was thinking of adding a safe() method (I have already done this for Observables and their extensions). Then I thought that if anything is thread-safe, it could just return itself from this method. This seems like it might be a good idea, except that most transformations do not affect thread safety, so they would need to basically re-create themselves using their roots' safe() instances. So the vast majority of the observable classes would need to implement the method. Almost all of these would be fairly trivial, but it's a lot of monkey work, and it's something that needs to be remembered for every future implementation.
In addition, a safe(Lock) method (already in Observables) might be useful, but I'm not sure yet. The place it would be most useful is in combinations, but then the combinations could just use the default safe() implementation. So maybe this is not needed.
I need to think more on this before I bloat my code unnecessarily.