Howto:Using Driver Hashes in Nasal: Difference between revisions
Line 60: | Line 60: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
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: | |||
<syntaxhighlight lang="nasal"> | |||
var myDriverHash = { | |||
"yasim": { some_property:1}, | |||
"jsbsim": { some_property:2}, | |||
}; | |||
== Problem == | == Problem == |
Revision as of 19:36, 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"] );
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
...
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.
== 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 <code></code>
<syntaxhighlight lang="nasal">
Background
Related
References
|