You know how we have modules, layers and environments for code but none of these concepts are actually IN the language?
Modules are typically self contained chunks of code that expose an interface to some useful logic. It is not important how it does what it does; but it IS important that we be able to find the module and call it. In most OO languages, we use functions or object/class methods to hold such logic, but then have to actually build the concept of module using user-visible mechanisms.
Layers are another conceptual tool for organizing code. This typically reduces to packages or namespaces, but neither of these concepts actually enforce a hierarchy or "can/cant call" rules. Similarly, it would make great sense for dependencies themselves to be layered this way, but no language that supports imports also supports defining the layer for those dependencies.
Environments - which I mean the container or context in which code runs - are similarly underspecified. Most languages define a main entry point and are call it done. Why not have a generic way of stating an entry point that includes a declaration of the environment (or even environments - plural)? The declaration of environment allows for the actual standup of said environment and trigger of the main code to be separated from the code itself; while the ability to declare that "this code runs in both gui and cli environments", for example, allows explicit declaration of such purity in the code and allows determining if this is true statically.
Well, this idea is to explicitly add those concepts to the language syntax itself.
The idea is that the implementation explicitly states the architecture assumed. Two advantages:
- The intended architecture is explicitly available to future developers
- Tools can be brought to bear on code directly, maybe even in the language
Of course, this does mean that the language knows only about specific types of organizing code. Within that limitation, however, things are much more clear, IMO.
No comments:
Post a Comment