Which came first...

I'm quite enjoying the flow I'm using to write this language binding - that of implementing an example first, and then going to the modules and adding all the necessary API to allow the example to 1) compile, and 2) run properly.

In some ways it's a little like test-driven-design, where you write your tests before you write the code that the tests, test. It's certainly nice to get to that point where you run the little application and everything is finally working as it should be.

Since the module API matches so closely with the Qt API/class structure, porting the examples is generally just a case of removing semi-colons, and converting -> into .

(well, okay, I'm obviously taking liberties here, because you need to instantiate the objects more verbosely, but otherwise that's it!)

An example? Okay...

Some C++ :

QVBoxLayout *leftLayout = new QVBoxLayout;

leftLayout->addLayout(topLeftLayout);

leftLayout->addWidget(caseCheckBox);

leftLayout->addWidget(fromStartCheckBox);

leftLayout->addStretch(1);

The equivalent BlitzMax :

Local leftLayout:QVBoxLayout = New QVBoxLayout.Create()

leftLayout.addLayout(topLeftLayout)

leftLayout.addWidget(caseCheckBox)

leftLayout.addWidget(fromStartCheckBox)

leftLayout.addStretch(1)

As you can see... the two are very similar.

You may be wondering why I require the Create() method call on the object instantiation.

I know, I could easily implement the New() method on the Type and have it create an instance of Qt's QVBoxLayout, but this complicates things if ever I need to create a BlitzMax QVBoxLayout object for an already existing C++ QVBoxLayout. (writing bindings can get your head in a spin!).

So, I generally have to "constructors" for each Type. A generic Function, and a Method. The nice thing about the method too, is that you can more easily implement your own subclasses of a given Type. (see any of the examples, where the main window/gadget does exactly that!)

:-)