Nigel Sampson
Nigel Sampson
Yeah they should both cause the same outcome, it's about the implementation and any side affects. I know some people (myself included) have hooked into the coroutine pipeline to add...
Interestingly we provide `Coroutine.ExecuteAsync` that will throw an exception if the coroutine fails. This method isn't used anywhere in the framework and is just a helper method. Will definitely want...
This one is proving a real pain to implement in a well designed manner. Having `Coroutine.Completed` throw an exception if there is an error won't work because `SequentialResult` catches it...
The more I think about this the more split I become on what the best solution could be. Not in terms of implementation but outcome. It might make more sense...
Pushing this to `4.0` suspect it need to be a breaking change.
Just posted a reply on the question, while it doesn't look to be caused by this it certainly has something to consider when doing this work. Ideally I think making...
It's nothing something I've looked into yet, but it should certainly go on the list.
Just confirming that replacing with `BindableCollection` with the out of the box `ObservableCollection` from the framework you're seeing the same problems?
Sorry to hear that, I don't have any quick fixes. What about replacing the list entirely freeing up the old list to be garbage collected.
Yup, at the moment it's only looking at count of the parameters and not their types. It should be possible to do type examination.