This would be sooooo nice, especially in DI heavy languages like Java. It might not be turtles all the way down, but finding the final turtle can be so difficult.
Designers will put much more thought into how best to interact with a framework, so start with a small, opinionated interface then consider extension feature requests on a case by case basis
I think some functional programming languages solve that by running a good chunk (if not all) of the application in a single trace.
And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""
For example in php class A { public $a = new B;} is not valid
Such a restriction makes no sense in a "closures are a poor man's object" world.
I think there is still hope on that front. Following structured concurrency patterns like the supervisor model should handle it. See the discussion about "Notes on structured concurrency, or: Go statement considered harmful" [1].
it's certainly not a given
No different from an object that got constructed and then a method called on it.
i thought you meant state that is created from a call stack and persists after that call stack returns -- which is something else