Although it is a contrived example, the code used captures the essence of Intention Space. The App in the Intention Space progresses through Design Chunks, and the execution code, in turn, is represented by the sequence of three 5-element vectors, which is determined at operation configuration time through the sequence => dc1.in1.ob1.in2.dc4.in2.ob2.in3.dc2.in3.ob3.in4.dc3, referred to as Design Chain Address [DCA]. As the execution proceeds, the DCA sequence carries a 'flow' object which picks up any new QnA elements from the Design Chunk as it is poised for execution, and then the DC member function can access the flow object to update QnA.
Value Proposition Of Intention Space In Software Development
Looking at every run time execution piece in Design Chunks through a static address formed at Operation Time
Intention Space, meant for creating a manageable and understandable software execution environment, has the built-in characteristics of being able to break up the design chunks into smaller and manageable development chunks too.
Intention Space tackles the hard problem of managing re-usability, modularity, and context maintenance over time in the software development process by bringing together the understand-ability of software code through intention progression along with the unique vector addresses of the executable components (design chunks) while also persisting the sequence of the vectors as the computation progress(i.e., in the context of the actual usage of the design chunk at execution time) as the locus point for the particular usecase.
An Intention Space addresses the Design Chunk code pieces through a shared pool of Intentions and Objects phrases. The fact that there is only one intention instance of a given phrase that joins an object and a code piece which, in turn, is open to receive any intention and reflect it to another intention, opens up the possibility of having a unique sequence (1 or more) of the five element vectors joining two Design Chunks corresponding to every possible execution instance of software codes generating the design chain address [Common Path for Understanding and Execution or CPUX].
Composing, Testing, Prototyping, Maintenance, and Security management through CPUX
With the CPUX defined at operation configuration time, we get a unique advantage over the traditional software architecture where at execution time instance of a traditional binary chunk of code can not be tagged with anything defined at operation time[e.g., a reactJS component can not be uniquely addressed every time it is rendered on the browser in the application lifecycle component rendering chain]. Intention Space is not bound by the inability of binary code to reveal intentions allocated to it at design time. By design, every Design Chunk execution instance in Intention Space gets a design time boundary address in the form of the Design Chain Address for the execution. This opens up the possibility of using CPUX for prototyping and use case verification.
In Intention Space, composing software pieces, testing them, prototyping and maintaining them can be controlled and managed through operation time-defined definitions of objects and intentions and design chunks.
This allows Intention Space to have a real advantage in not only software maintenance but also in software security handling. Because the intents of any software code can be exposed without revealing the software code, it allows us to develop a security protocol based on the agreement of intentions before the use of any code. The detail of these implementations is in progress.
Managing Intentions, Objects, and Design Chunks
The advantage of Intention Space solely relies on our ability to manage Objects and Intentions at operation time while easing the cognitive burden on the designers and coders while making the software. A typical App can have hundreds of Intentions and Objects with QnA sets and subsets adopted by the design chunks. As Intention, Objects, and Design Chunks are identified by human-readable phrases in natural language, managing them well so that designers can choose the right Intentions, Objects, and Design Chunks and reuse them or map QnAs between different design chunks is a good challenge to be solved by the present day Large Language Models of AI. Suppose we can accurately identify intentions and objects that cross subject matter boundaries. In that case, it opens up possibilities for creating new language models to bridge different domains and facilitate more advanced and specialized natural language processing tasks.
When Objects Are Only Intention Reflectors To Behaviors - Absence of Hierarchy