Op ma 24 nov 2025 om 15:03 schreef Rowan Tommins [IMSoP] <
imsop.php@rwec.co.uk>:
> - SDK Susie does not know what implementation of LoggerInterface will be
> passed to her library. How does she know if it is safe to use in her
> asynchronous code?
As the LoggerInterface is injected into her SDK client and there is no
distinction between an async and a sync Interface, Susie can't and doesn't
really need to know this. She just uses the contract that is implied by the
interface.
> - Legacy Les is using a LoggerInterface implementation written years
> ago. How does he know whether it is acceptable for use with Susie's
library?
As I see it, there's two kinds of "acceptable" in this case: blocking vs
non-blocking and possible side effects.
Blocking vs non-blocking:
If Les does not care about blocking the event loop he can do whatever he
wants. If he passes a Logger with a blocking I/O call (for example through
some extension) the event loop would block for the duration of the I/O
call. Acceptable in his case, as he does not seem to care about async.
If Les wants to take advantage of non-blocking I/O he has to use a Logger
which implements one of the non-blocking I/O functions (file_put_contents,
...). In this case I would expect the Scheduler to await that function call
in the current coroutine. Is this correct Edmond?
Possible side-effects:
It is however possible that the expected output of the logs may have a
different order than before Susie migrated her library from sync to async.
Depending on how you look at it this might be a problem. I would expect
Susie to release a new major version warning users of a possible break in
backward compatibility. If Susie does not do that, Susie is at fault. If
Susie does release a new major version I would expect Les to fix his
dependency on shared state before upgrading to a new major version instead
of blindly upgrading to a new version*.
* which he shouldn't do anyways, async or not.
Is this helpful?
Best Regards,
Bart Vanhoutte