Moment := micro + component

Components 2020 aka ECS

I have just realized there is an “Entity component system” architecture in full swing these days.  I very often use gaming development as proof something works or does not work in reality.

To me, ECS is very encouraging proof that the best application architectures are constantly repeating the same overarching theme: Components. Often independently of each other.

Then I remembered I did this Java Script component-based idea 10 years ago, Interesting. Read on.

[2010 JAN 17]

Is there anything like a “pure object run-time environment”?  (For some reason we use the acronym “OO” when we mean that.) Since “primordial” OO, we have come to understand that OO run-time should consists (basically) of objects which are sending messages to each other. And nothing else.

Objects + Messages = OO

The “small” side issue is that since then, no one has yet come up with a consistent and universal definition of these. Therefore we still have no general consensus on what is the “object” and what is the “message”. Also, we have realized there is an infinite number of infinite levels on which this “fuzzy” architecture indeed exists and repeats itself. Like a Mandelbrot pattern of the software universe. Objects and messages, objects and messages, objects and messages … ad infinitum.

Back to reality. I can actually not remember seeing anywhere, “clean-cut” run time environment, which implements this simple architecture? The run-time environment where there are only objects and messages. Something like this :

No methods, no properties. Just messages. And a micro mechanism for receiving (aka “taking”) a message. In case you thought of SmallTalk run-time, this is (at least for me) much cleaner than that obviously.

Now, should we try to “dig deeper” perhaps? I can explain that I will implement this in a JavaScript (as YAL: Yet Another Language ). “Grammar” sketch is this :

Method remember is used for object implementations. This is an environment which on the global level uses the above-defined abstractions. Bellow that (enclosures) there is standard JavaScript. There is no communication between closures, besides through a mechanism described. Now, let us see how do we define implementations.

The implementation is made of normal, but all “hidden” JavaScript objects and this “message-based” global-space environment. Calls to the “answer” method are only asynchronous. There are no synchronous calls.

It seems this way, I have actually described a component (global-space) layer inside JavaScript programs. Which is (remember Mandelbrot) the same architectural pattern, found one level above, and the level above it, in the SOA universe. So why do I not redefine all of this as a micro-component JavaScript mechanism?

Not catchy enough

And since “micro-component” is not catchy enough I shall call my micro component: “moment“. (perhaps: micro + component = moment ? ). Ok here we go, then.

Of course, I shall use a JavaScript code to define this. ( this should make it more clear ). I shall also use this opportunity to rename “answer” to “react”. Which is a name, that I think better describes the purpose of the function: ask the object to “re-act” on the message you are sending.

Implementations required above are not defined here. This is just an application architecture sketch.

Important to understand is that in here, standard JavaScript code is not allowed in the global space. Only inside callbacks, and inside closures. In this scenario, global-space should contain only Moments of exchanging messages. And callbacks inside which application logic gets implemented with standard code.

Remember how we started

searching for a pure “runtime” environment. This prototype is more of a “global-space in javascript applications” but still valid.
It is easy to imagine JavaScript pre-compiler which will enforce these rules and global space Moments.

Work in progress…

Entity Based System diagram found on the ancient scrolls
Entity Based System diagram found on the ancient scrolls