Howto:Using Driver Hashes in Nasal: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 33: Line 33:


};
};
</syntaxhighlight>
Now, instead of adding key/value pairs directly to the hash, we can also add a nested hash:
<syntaxhighlight lang="nasal">
var myDriverHash = {
"hash1": {},
"hash2": {},
};
</syntaxhighlight>
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:
<syntaxhighlight lang="nasal">
var myDriverHash = {
"hash1": { value:1},
"hash2": { value:2},
};
print( myDriverHash["hash1"] );
print( myDriverHash["hash2"] );
</syntaxhighlight>
</syntaxhighlight>



Revision as of 19:32, 14 October 2017

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.

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"] );

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

...

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.

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

Background

Related

References