Howto:Using Driver Hashes in Nasal

This article is a stub. You can help the wiki by expanding it.

Objective

Demonstrate how to put context specific functionality (APIs) into so called driver hashes to easily switch between different front-ends or back-ends respectively. The same mechanism can be used to easily provide support for backwards compatibility, by putting version specific implementation details into a corresponding driver hash (example to be added).

What is a driver hash

It's a conventional Nasal hash (imagine it like a namespace), which typically contains callbacks, i.e. functions. Driver hashes are usually nested in an outer hash, where a key can be used to look up the concrete implementation.

This is an empty hash named myDriverHash:

var myDriverHash = {
};

To populate the hash, we need to add keys to it - in this case, this can be best accomplisheed by adding strings to it, with a color specifying the value:

var myDriverHash = {

"key1": "value"

};

Different key/value pairs are separated using a comma:

var myDriverHash = {

"key1": "some value",
"key2": "another value",

};

Now, instead of adding key/value pairs directly to the hash, we can also add a nested hash:

var myDriverHash = {

"hash1": {},
"hash2": {},

};

Now, myDriverHash contains two keys, each pointing to another hash - which is empty for now, these can be accessed using the key to look up the field in the namespace:

var myDriverHash = {

"hash1": { value:1},
"hash2": { value:2},

};

print( myDriverHash["hash1"] );
print( myDriverHash["hash2"] );

Instead of using arbitrary names for the keys, we can also use names that are self-explanatory to tell the reader what the hash is trying to hide/encapsulate, for example:

var myDriverHash = {

"yasim": { some_property:1},
"jsbsim": { some_property:2},

};

Problem

We have an increasing number of similar features that are sometimes even mutually incompatible, often this applies to features for which different alternatives/approaches exist, for example:

• JSBSim vs. YASim
• Basic Weather vs. Advanced Weather
• Rembrandt vs. ALS
• Phi vs. PUI
• osgEarth vs. the standard scenery engine
• navdb vs. navigraph data use
• online weather service vs. the local weather system
• main aircraft vs. AI/MP aircraft
• geodinfo() vs. the hard-coded terrain presampler

...

However, Nasal scripts may need to work with all of these components, regardless of the concrete implementation - this is where we commonly see spaghetti code using lots of nested if/elseif constructs to deal with the differences among these implementations.

But this is exactly where it pays off to simply encapsulate implementation specific details into a hash with callbacks that can be easily switched.

Use Cases

This kind of functionality could be used to support custom styling/theming for avionics that have otherwise overlapping/identical features, but mainly differ in terms of appearance/looks.

Example

Let's imagine, we have a piece of Nasal code that needs to work with different FDMs (or autopilot/route manager configurations).

The YASim property may be named

Related

References