How does a business logic object access other aspects? The connection can be dynamic and static.
Dynamic connection means something that the code accesses "right now" and it can change. Like in the messenger application, get a list of messages and select one. The selected and displayed mail is a temporal connection to a message, you can select another message and switch the display to it.
A static connection is something that the actual code can't change, only uses them, it creates the environment where the code is running. There are known examples for this in "standard programming": this is the Runtime for a static application, or the Servlet Context / Session for a web service; the start up parameters and the Environment variables, content of a configuration file or servlet / context xml.
In Dust this goes further. In standard programming, the code contains the function and member variable names, static / global variables. They are resolved by the compiler and linker to memory offsets and jump table indexes, burnt into the binary (and causing unwanted component dependency network, version compatibility issues and the "dll hell").
Here you have aspect references only. Simple put: you have dynamic aspect references to object that you want to work with; and static references for telling what you want to do. When you declare that you want to use a certain type, field or shared instance, you actually issue Dust to generate a new constant: an index in a reference table through which you want to access that field or instance. The signature of your implementation contains this list with the referred identifiers, and when your code is active, this list is resolved (either immediately or in lazy-fashion: when first referred to) to actual type and field references - which are Aspect instances again. When you refer to a field, you actually use an index in your reference table, and behind it you get the aspect instance defining that field (and actually knowing not only the memory offset of that data, but all other settings like type, life cycle, access rights, etc.) The code there is responsible for giving you the content of that field from the actual Entity instance (which is then required to contain the memory for all the aspects with proper offsets again).
This finally answers the oldest question of mine: what is an "initial" Dust application and how it starts? The minimum Dust is the meta entity (Type, Aspect, ...) instances in a self-containing Context, with all their static references resolved to each other in code level (this code is generated from the core configuration). The core configuration can be extended to the required types, and we have a static-typed application (no type or binary loading, upgrading, like a GWT presenter); or even to all the entity instances (and we have an embedded application with no dynamic memory management). Of course, memory management and type / binary loading is the "next ring" of Dust kernel, above the absolute necessary core.
I still have issues with the Reference management. It now seems that Aspect instances can only contain generic variables; references to other Aspects require special care, using Containers and / or a dedicated Reference manager. This will be the next run.
