I am interested .... in contributing. As you may have seen, I actually started something like this in the current newsletter:
http://wiki.flightgear.org/index.php/Fl ... or_newbiesThe idea was basically the same. I just wasn't sure about the most suitable format, I was thinking of either having a monthly (or even weekly) column in the Nasal forum or simply adding those things to the newsletter, like I did a couple of days ago.
I was actually planning to do this for a quite a while, to help populate the Nasal forum. And to help new users to get started coding in Nasal.
It would also not deal with Object Orientated Programming (because I don't know much about this).
I can handle that part, but there is also a pretty good introduction in the Nasal wiki article.
And I even posted a very basic introduction in the local weather thread, when we were talking about turning some of that code into OOP style:
http://www.flightgear.org/forums/viewto ... =15#p70986OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created.
These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.
In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods".
For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);
That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.
This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.
Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.
So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).
Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".
Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".
Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.
For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.
This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.
Of course, one may still use objects like conventional variables for passing and returning parameters.
Other things that I'd personally be interested in, would be having introductions for functional programming in Nasal, as well as multi-threaded programming using the threads module. That should help increase its adoption, as well as foster the process of making all Nasal APIs fully thread safe.
I really think improving the existing Nasal documentation is an important step to make it easier for people to contribute by scripting.
The homework/assignment idea is actually interesting, but I am not sure if it's too much work?
Personally, I was really thinking in terms of either having columns or "mini howtos".
I am not sure if I could really help with reviewing assignments and such, while I am pretty confident that mini articles would be useful either way...
For the time being, I have added all suggestions to the wiki:
http://wiki.flightgear.org/index.php/Nasal_introductionThere are probably other potential contributors who have done their fair share of Nasal programming, like flug, xiii or AndersG ??