We may be talking about different things.

If we can expect that `HeartbeatActor.class` is defined to be the same thing anywhere in the dependency hierarchy, though, then the…

We may be talking about different things.

If we can expect that `HeartbeatActor.class` is defined to be the same thing anywhere in the dependency hierarchy, though, then the criticism still stands — we have, somewhere, a pool of associations between abstract types and the concrete types we prefer to use for them, and if that pool of associations is readable when we are constructing part of it, then we can avoid looping dependencies just by checking it.

However, if we’re talking about a situation where a constructor *must* be called, and that constructor *may* inject a dependency (whose constructor likewise *must* be called), it’s not so easily avoidable.

(In the python example, module loading can happen anywhere in code & even conditionally, so it’s a purely runtime concern. Simply making import idempotent by having it check the pool is sufficient to avoid dependency loops.)