| Subject: | Possible way to get loop-aware subclassable Futures |
Currently, $loop->new_future returns an instance of a loop-specific Future subclass. This does not play well with custom subclasses in libraries built on top of IO::Async.
One possible way out of this, which should maintain back-compatibility, is:
* Future->new can take a 'await' coderef param, and its 'await' method just delegates to it
- existing subclasses keep working, because they override the method
* Loop->new_future passes something like await=>$self->curry::_await_future to the $future_class->new call
- older Future classes should just ignore it
- newer Future classes will store it but not use it because loop-specific classes still override the method
* Loop->new_future can take a class name or a factory fuction, and use it instead of the $future_class
- no existing code passes anything to new_future, so this can't break client code
* at this point we can stop defaulting the $future_class to a loop-specific subclass, and just use Future
* document the whole thing, and we're done
It may even work!