Design¶

ec is a module launcher. It’s a simpler and better implementation of commander. It is designed to shed some feature creep and to provide a better UX.

Design Goals¶

Using simple functions,lambdas and callable classes as types, bot for conversion and validation.
Nested args, by using tasks as types.

docstring and external configs, thus eliminates the need for validation and generation.
Batch, TUI, Web and Proxy modes.
Hooks.
Standard helpers.
Development utils, like debugging etc.

Config API-s are to be implemented as routes (inspired by bottle), hence docstrings are freed up for other purposes (especially for documentation).

The args follow a argName=value pattern for enhancing readability, especially on the dispatch mode.
The config decorators return the underlyings, instead of their decorated versions, so to allow a hassle free use of the underlyings within the script.

scriptlets - plugin like mini-programs that could accomplish specific tasks.
Example script to serve as the documentation, as well as the targets for the tests. To keep it DRY.

With experience errors get reduced.
Simpler structures are often robust.
Writing tests is a lot simpler than imagined.
Configurable code (code tht could be manipulated through data) is more structured.
Visualizing the data flow helps with creating better structures.
Programming is not software engineering.
Reading good code could help writting good code.
Data inputs should be preserved, they might have additions, but not editions or deletions.
Complex and humongus classes makes the implementation inflexible and complex to understand. In a flexible design classes should be simple, with most processing happens in flow (the path of functions, through which the objects of the classes pass through). In other words: A program with a more functions that handle simple objects is more flexible than a programm that combines classes to achieve the same.

The methods to be used by the loaded scripts are added to __builtins__, in order to avoid an explicit import of ec from the script; which will load a separate instance of ec and complicate the passing of data between the two instances.
150630_1500 Decided to add an attribute __ec_member__ the underlyings, to identify them for ec. An alternate implementation was thought of; in which the underlyings and the members would be buffered (as a list / dict) and processed before starting the core. Though the later method doesn’t alter the underlying, the former is chosen for it’s simplicity. It took ~30 mins for the rewiring.
150714_0400 Decided to use an explicit method modules.config.member to facilitate the addition of imported members; instead of automatically scanning the scripts for importables. This is because “Explicit is better than implicit”.