The problem was that the language bindings were complex and error-prone, and, while I could make the language bindings easier to use, I think the qpp solution is better, because with qpp:
- the language bindings can be abstracted from the actual/current implementation
- language documentation from doxygen-style comments can be generated directly from the language's source code
- a great deal of repetitive code can be generated automatically
- (later) the documentation comments can be incorporated internally to provide additional information in reflection-like internal and external APIs
In the qpp file, function, constant, and classes are defined in a Qore-like syntax (with some additional information for internal tags, functional domains, etc). The bodies of each function or class method are then written in C++ (hence Qore Plus Plus).
For example, here is the qpp implementation of the Dir::path() method:
/! Returns the path of the Dir object or @ref nothing if no path is set /** This path does not necessarily need to exist; the path is adjusted to remove \c "." and \c ".." from the path if present @return the path of the Dir object or @ref nothing if no path is set @par Example: @code my *string $mypath = $d.path(); @endcode */ *string Dir::path() { return d->dirname(); }The current pre-release documentation based on Doxygen for Qore 0.8.4 can be found here: http://qore.org/manual/qore-0.8.4/lang/html/index.html
I won't be able to get to many optimizations using qpp in this release, because first I want to clean up the namespace code and some related changes. However, qpp lays the groundwork for making easy infrastructure changes to Qore in the future - we'll be able to implement new solutions in Qore and then apply them globally to all language bindings by extending qpp.