Since every script runs in a separate scope, it is difficult to share code or data generated by one script with another script that is run at a later time. You can write a library and include it in both scripts, but each script will get its own separate copy of the library code and changes made to library objects in one script will not affect the other. You can store a setting in one script and read it from another script, but this is limited to data that can be stored as a string. Named objects offer a solution to this problem.
The named object database is a shared collection of script objects maintained by the application. It is initially empty when Strange Eons starts, but scripts can add a property name to the database and assign it any object that they want. The same property can then be read by other scripts to get the same object back, and changes made to the object in one script will be visible to every other script.
Named objects live in the main application object, which can be accessed in every script using Eons, under the namedObjects property. To create a named object, first create an object with whatever properties you wish to share with other scripts. Then store this object under Eons.namedObjects with the desired name. For example, this will create a named object called myNamedObject that has properties called aNumber and aFunction:
const theObject = {
aNumber: 6,
aFunction: function() { alert("Hello"); }
};
Eons.namedObjects.myNamedObject = theObject;
Once defined, you can access the same object from other scripts by reading the value of the same property:
// in another script:
Eons.namedObjects.myNamedObject.aFunction();
You can test if a named object has already been defined by checking for a null value:
if(Eons.namedObjects.noSuchObject === null) {
// ...
}
Note that unlike a typical JavaScript object, missing properties are not undefined.
You can use this technique to write a script library for your plug-in that creates the named object if it does not exist, and otherwise reads the existing object and assigns it to a convenient constant. Then you can load the library in any script that requires the object, and the first script that runs will create the object.
As a precaution, you can’t assign an object to a named property if it already exists. It is generally not necessary to replace a named object; instead you should just add, remove, or modify properties of the object itself. However, if you really need to replace a named object, you can do it by first deleting the original property with the delete keyword:
delete Eons.namedObjects.myNamedObject;
Rather than creating a different named object to store each value you want to share, create a single shared object for the entire plug-in and add all of the values you wish to share as properties of that object. This reduces the likelihood of two plug-ins trying to create objects with the same name.
For most plug-ins, a good place to create a named object used across that plug-in is in the initialize() function. Likewise, the unload() function should delete the named object so that its memory can be reclaimed. (You can skip this step for extension plug-ins, since they are only unloaded when the application is quitting.)
Java code can also access the named object database, but the API is different:
StrangeEons app = StrangeEons.getApplication();
NamedObjectDatabase namedObjs = app.getNamedObjects();
// get a named object
// equivalent to: let obj = Eons.namedObjects.objectName;
Object obj = namedObjs.getObject("objectName");
// create a named object
// equivalent to: Eons.namedObjects.newObjectName = someScriptOrJavaObject;
namedObjs.putObject("newObjectName", someScriptOrJavaObject);
// delete a previously defined object
// equivalent to: delete Eons.namedObjects.nameOfObjectToDelete;
namedObjs.removeObject("nameOfObjectToDelete");