3 ms·
You start with reification of some part of your system/codebase. Once you have that, it's easy to adapt things. For example, in an OO context, once you've obje
by toolslive 3y ago
You start with reification of some part of your system/codebase.
Once you have that, it's easy to adapt things. For example, in an OO context, once you've objectified your method call instance into an object that has reference to the caller, callee, parameters and the code to execute it's easy to log it, decide if the caller needs to be authorized aso...
The are some other considerations like when (compilation time, run time, ...)
It's a really interesting code organization strategy and the only problem I've experienced with it is that (for example decorators) introduce a static layering (the order of the decorators) that works against the inter-aspect dynamics.
For example, a call only needs to be logged if there is a necessity of authentication in a distributed context. In essence, you might not be able to have a static ordering that works for use cases. (security on top, or on the bottom ?)