#16 GGI 3.0: Metacomponentry
At some point, the challenge of making all possible C++ abstractions available in C, which core GGI is far on its way to, will need to be completed. In principle, all that is needed to do this to enhance the number and type of interfaces exposed by the GGI dynamic library components:
* Standard inputs and incoming buffers
* Standard outputs and outgoing pipes
* Internal structures for templating morphological control
* Encapsulated control structures for transport, management and processing
* Typed generic interfaces defined externally in some metacontrol system
* Synchronization flow and control
Whereas standard OOP is often confusing and hard to follow, the categorical nature of the component-library basis GGI uses is worlds easier to design with, implement in various strategies and interface with almost any type of legacy code or environment. It even scripts well using one of the many standard scripting languages, and GGI aready has the ability to be statically or dynamically compiled so performance vs. flexibility is not and issue.
Reflect on the future of systems programming, and you will see component flow. That is a given. The LibGG core of the GGI system is currently hands-down the best C-language standard for implementing this sort of environment, and as such I expect it to replace C++ and distributed object systems in higher-level languages in terms of performance, flexibility, ease of use and ease of understanding in whole or in part.