‘Babel’ – The new release of Essence# which focuses on integration issues

Unlike the situation with most programming languages, an Essence# programmer is expected to add to and even change classes and methods in the language’s standard library. And the same would be true of any classes or methods defined (owned) by those who publish class libraries meant to be shared with and used by others (whether “open source” or otherwise.)

But that creates a problem whenever the time comes to acquire and integrate with a later version of a class library for which the programmer isn’t the principal author, but which he nevertheless extends or even modifies. The Essence# Standard Class Library is one example, but certainly not the only one.

A perfect solution to this problem would automagically merge all changes made by the publisher of the class library and the clients who extend or modify it. Perhaps in times to come, artificial intelligences will take care of that for us without us having to worry our inferior wetware brains about it, but that time is not yet. Nevertheless, Essence# does have a somewhat unique solution to this problem, and I’m going to use this “release announcement” to describe and explain it.

To understand the Essence# solution, it is first necessary to understand how class libraries work in Essence#:

An Essence# class library is a container of namespaces, which in turn are containers of classes and/or other namespaces. Of course, that’s pretty much the definition of both of those terms in most modern programming languages, so nothing new there. So here’s where Essence# diverges from the norm:

• An Essence# class is also a namespace. It has all the same behavior, capabilities, features and functions as an Essence# namespace. And Essence# namespaces and classes are objects. They can be sent messages at run time. And those messages can modify or even totally redefine the namespace or class to which they are sent.
• It’s possible for the same class (or namespace) to reside in multiple namespaces–even under different names–because the identity of a class or namespace at runtime is a function of its identity as an object, and not a function of its name.
• And it’s also possible for the same classes and namespaces to be defined/declared in different class libraries. Two different Essence# class libraries may define completely different namespaces, classes and methods, or they may define all the same ones, or (far more likely) they may mostly define different namespaces, classes and methods, but have some (usually small) overlap. This is possible because namespaces, classes and methods are not created and grouped together declaratively, but instead by means of message sending. If namespaces, classes and methods were defined declaratively, then any differences between how they are declared in one class library and the way they are defined in another would create a logical contradiction, because logical declarations are universal invariants which must hold everywhere for all time. Since Essence# namespaces and classes are intrinsically dynamic, differing definitions do not create a system panic: The system is designed to permit such things to change over time. So, if “the same” class can differ from itself from one moment to the next as the program runs, then it can certainly differ from itself with respect to how it is defined in various and sundry class libraries. Therefore, such differences need not–and do not–cause any errors at compile time.
• An Essence# code base can and does contain what would, in a static language where classes are defined declaratively so that their name, form and behavior are invariants of the system, have to be treated as “logical contradictions,” and so disallowed as compilation errors. In Essence#, one dynamically specifies which class libraries will be loaded into the execution environment, and in what order. That is how different class libraries are merged together into a unified whole for a specific invocation of a program, where the last library loaded “wins” any disagreement over the definition of a namespace, class or method. Even better, a class library that merely wants to extend a class by adding a method can do so without a) knowing all the methods defined for the class by any other class library, and b) without thereby deleting all those methods it knows nothing about. The same is true for any methods it modifies. To put it another way, Essence# does not operate using the “closed world assumption” that if a class library does not assert a fact about a class, then that fact must be false. The messages a class library sends that construct or modify a class are never interpreted by the system as the final and complete definition of the class, to the exclusion of the “declarations” made in other class libraries about the same class.
• Finally, Essence# class libraries are always stored separately from each other. That means they can change independently of each other, even when they define, or modify the properties of, the same namespace, class or method. That also means that that a new version of one library has no effect on the code of another, ever–even if they define the same class or method. Yes, they still may conflict with respect to the form, structure or behavior of a class, but such conflicts would only matter when both are loaded into the same execution context. More importantly, such conflicts can be resolved by yet another class library whose sole purpose and function is to modify the namespaces, classes and methods that have been loaded into the execution environment so that they operate together usefully, and as intended by whoever put them together into a unified solution.

So Essence# handles integration conflicts by a) keeping the “(source or object) code of record” of class libraries distinct from each other permanently, and not just as a necessity of packaging and/or distribution, b) enabling full dynamic control over which class libraries are loaded into the execution environment created when a program is launched, and providing full control over the order in which the class libraries will be loaded, and c) using and embracing the dynamic malleability of objects, including those that are namespaces, classes and methods, instead of fighting against it.

The ‘Babel’ release can be downloaded from the Essence# site on Codeplex.