Meta-meta layer
- identigilo: Generic variable type for identifying core data elements: attributes, messages, references. Atomic information, general implementation is an ASCII string identifier (small and upper case English characters, numbers, underscore). Has NO functionality, works like generic constant variable for declaration-level codes (like a GUI display or expression); high level business logic components "see" the identifiers through generated source constants (enum and alike). Not to be confused with the unique identifiers of entities (although it works as that for the core elements, but only within the closest context).
- variablodeklaro: The declaration information of one variable, either a local temporal value in a certain context or a member value inside a type. This connects an identigilo to a usage information structure: data type, life cycle (constant, final, modifiable, etc), ... contained within this component. The identifier must be unique in its actual context, as the value is referred to by it. The type may either be a generic type or a (single or multi-value) reference to other aspects. Handling references is different from generic data, but the identification, passing and resolving should "look similar", especially in expressions and language constructs, this is why they both covered by this component. Side note: "value set" for option selector is handled by a set reference to other entos in this type: the elements of that enumeration are entos themselves. This is different from
- tipo: This is similar to the normal "type" or "class", contains 0-n variablodeklaro elements forming the "data context", and a list of other tipos that it can accept. All kondutos (business logic) are implemented as being inside the context of an aspekto ("object instance of tipo "class"), that gives the "member variables and references". All logic entry points are reactions to an incoming "message": ento with the primary aspekto of the referred tipo. Furthermore, each tipo contains 0-n "required" tipo elements, which are also required to exist in the same ento. The business logic can refer to these other aspektos of those tipos as present, this feature provides behaviors similar to inherintance without the forces tree structure.
- datumo (generic type) wrapper type for generic types handled by Dust: boolean, integer, etc. The common set is extended by identigilo, which is also a "generic type" in Dust. Funny question: I started reducing this set by saying: no, string is not generic, float is not generic; what remains? Integers with different byte size, like in assembly, and the special identigilo. Am I surprised?
Meta layer
- aspekto: This is similar to the normal "type" or "class", although in Dust you have no independent "Object instances" by an aspekto. It contains 0-n variablodeklaro elements forming the "data context", and a list of other aspektos that it can accept. All business logic are implemented as being inside the context of an aspekto, that gives the "member variables and references" of the business logic. All logic entry points are reactions to an incoming aspekto "message". Furthermore, each aspekto contains 0-n "required" aspekto elements, which are also required to exist in the same ento. The business logic can refer to these other aspektos as present, this feature provides behaviors similar to inherintance without the forces tree structure.
- ento: Entity, a programming object instance inside Dust representing a "being" either in the outer world (like a person, a booked resource, ...) or inside the virtual world of the running environment (like a GUI element, an event message or even an exception). Each ento has at least one aspekto, and always have a primaraaspekto, which the ento "is".
- kunteksto: container of entos and their relationships. Responsible for storing, resolving ento instances and also for their relationships (which is not stored inside the entos). The kuntekstos form a tree, the root is the first, meta-kunteksto. The connection is invisible for the entos inside, any resolution request not found in the current kunteksto is passed up to the parent until the root. The root kunteksto contains itself as a normal ento, and (as far as I think now) all the other kunteksto instances as well. However, a child kunteksto may contain internal kuntekstos acting as a "virtual machine".
Term context
Service layer
- vendanto (vendor): the responsible owner of terms and behaviors, responsible for the coherence and the unique identification of the provided element tree.
- bieno (domain, field): the higher area of connected terms. From the application point of view, bieno is the highest level: "all" terms that are handled by Dust has to be distributed into disjunctive, coherent subsets: these domains. However, this is life, different owners can have altering ideas of these domains, their separation and content, there can be multiple, competing alternatives. So, Dust does not try to enforce its own structure as "the" solution, the framework (as meta layer) is designed to handle multiple approaches from different vendors (Dust is only one of them). This is why bieno is under vendanto.
- unuo: a "working unit" inside a bieno. Unuos contain a set of tipos; and an optional list of referred unuos. The tipos can only refer to other tipos from the registered unuos. The Dust running environment ("an application") consists of several unuos, where these references are all resolved within the set, so all used tipos have their declaration and behavior loaded.
Service layer
- konduto (behavior): the application logic assigned to a tipo. The konduto itself is stateless, exists in one instance, has no "member variables" in any programming language. However, is can be stateful by injecting a workarea object into the aspekto that it handles, so when needed, it can analyze the data (publicly available and handled by Dust), but store local information to it to speed up processing. However, such entos will be harder to serialize (for example).
- realigo: an unuo has a single declaration, but possibly multiple implementations for different actual running environments, like drivers, GUI display frameworks, etc. A vendor an provide multiple realigos for the same unuo, even for unuos from other vendors. Entos representing an actual hardware have to be bound to their own realigo. The realigo contains kondutos for some or all of the tipos in the unuo. Question: what happens when a specialized konduto for an ento refers to a shared ento that has different kondutos in the available realigos?
- sendito (behavior container): in the kunteksto, this component contains the kondutos of the knows tipos. Responsible for calling the proper method with the target aspekto and the received message ento.
