Hello Pedro,

There have been plenty of attempts to provide that kind of functionality, Aspect Oriented Programming (AOP) being an example of a language level attempt while others have relied on clever editors. It can reasonably be argued that the way modern IDEs allow you to slice and dice a code base provide exactly such capabilities. I personally believe that this kind of tool could be helpful for certain kinds of browsing/debugging but that they can’t replace code units for reasons related to this article. Organization of code into independent units should not be just an answer to the question “Where do I put this class file?” but a tool to control complexity by providing the reader with guarantees (like “I know that this code only calls these particular methods because that’s all it knows about.”). Such properties are only guarantees if they hold regardless of how you currently chose to view the system and to me this implies that there need to be a dominant hierarchy of components which provide them.

In the article I essentially argue that package level code organization should be used for the purpose of constructing components which provide such guarantees instead of wasted on some weaker organizational concepts (such as by kind or by creation date). Removing either of the class, package, or project levels altogether seem to be quite contrary to such a goal.