The blocks might end up calling each other or otherwise using self and then the ramifications are not easily tracked.
I like it in principle, but give it a more formal construct that includes the promise that no more than 1 of them will be asked for and they are not interdependant. Said construct could also help with syntactic sugar if the final way of writing the contexualizer methods isn't quite so pretty (simple method names easily conflict with regular use; it's a shame to reserve them).
—John
| [reply]
[d/l] |
The blocks might end up calling each other
That doesn't matter if they're not called.
I like it in principle, but give it a more formal construct that includes the promise that no more than 1 of them will be asked for and they are not interdependant.
IMHO that's a (premature) optimization that can be added later, when a compiler actually wants to do such an optimization, via a trait or so.
That said, if somebody comes up with a nice syntax for them, why not?
| [reply] |
I mean the one that is called might have dependencies on others.
| [reply] |