Internals of libQuixie

It’s been (at least) 9 months since I started prototyping libQuixie, the will-be KonsolScript scripting engine supporting Object-Oriented Programming.

As much as I’d like to implement it in C, String-handling with dynamic memory allocation kept me from any progress.

Having been convinced by Gnash developer Rob Savoye, I decided to use C++ instead, which indeed made the progress to move forward.

Still wanting to support C, I designed the C++ code to be easily ported/adapted by C programmers. But having been working on-and-off on libQuixie with C++ for about 4 months, the whole code seems to be a mess. So I decided to draw a diagram of how things work inside libQuixie, which would hopefully help get a better visualization of its inner workings.

Above is the architecture (if you may) of libQuxie’s variable handling, showing how it will support Object-Oriented Programming.

A quick walk through: If a user declares an instance of a class (given that it’s pre-existing), this new instance will be handled by ClassInstancesArray where the index is kept in VariablesArray; then all reference to the newly created class-instance will have an ID of the VariablesArray-index, that points to which ClassInstanceArray-index it’s kept.

Basically, the {whatever-type}Arrays are the Manager class of each {whatever-}type, which would handle the checking of variable-duplicates and such.

This might be confusing, and it is, but this design is made with easy C-porting/adaptation in mind. Also, this is a prototype — and so arises the question “will it be performing fast?” that is answered with “I’m not sure but I hope so”.

If you have any concern about the design, feel free to discuss it below — I do need your inputs on this.

Still working on the code. Everything is way too preliminary, so an announcement of an alpha release is way too early.

Will try to SVN-commit the draft and messy-prototypic code this week.

~creek23