Blitz Lua Object Interface

lua-users home

This page describes the "object interface" of BlitzLua, a Lua runtime environment written in BlitzMAX.

BlitzLua Object Interface

The "object interface" directly maps BlitzMAX types to a corresponding Lua "class", i.e., a table with an associated metatable. All tyes of a given BlitzMAX module reside in a Lua table whose name is that of the underlying module: e.g., under Lua, the BlitzMAX type TGadget found in module BRL.MaxGUI is replicated by brl.maxgui.TGadget (with brl being a global table). An optional "import" mechanism makes all types of a given module global, removing the need to prefix them with their module name.

Naming Conventions

Since Lua is a case-sensitive language (whereas BlitzMAX is not) the following naming conventions apply:

In case of any incertitudes just consider the type reference which is part of the package.

Parameter Handling and Type Conversion

The Lua function parameters equal those of the corresponding BlitzMAX method, any default values are properly respected (i.e., the corresponding Lua argument may be nil). Types are converted as follows:


Noteworthy detail: while the "function interface" passes BlitzMAX objects as "light userdata", the "object interface" works with Lua "objects" only. As a consequence, the interface implements a look-up technique in order to retrieve the Lua table for a given BlitzMax object and vice-versa:

It is therefore the "_Peer" which is passed to a BlitzMAX function, whereas every object returned from BlitzMAX is looked-up and replaced by its associated Lua table (if such a table exists, otherwise a new one is created "on-the-fly")

Any BlitzMAX constants are also available within the table belonging to the defining module - their names have been kept in uppercase (e.g. brl.event.EVENT_WINDOWCLOSE) as under BlitzMAX.

Some Details of the Object Interface

The interface "classes" provide prototype-based differential inheritance (which actually means, that modifying a "class" immediately affects all its instances, unless the modified field is "shadowed" by the instance). Additionally, they manage the lifespan of their "_Peer": using "keepers" (see BlitzLuaKeeper), every Lua "object" gets informed by the garbage collector when it is to be removed from memory. It then invokes its destroy method, which properly shuts down and removes the associated BlitzMAX peer.

When using both the "function interface" and the "object interface", you should not mix functions working on BlitzMAX objects and Lua "methods" unless you really know what you are doing. Using other functions (which do not deal with a specific object) is, however, safe (and often necessary)

Compared to the "function interface", the "object interface" allows for an object-oriented notation and frees the programmer from the burden of having to manage BlitzMAX objects him/herself.

The "object interface" has not yet been finished but will hopefully be published around May 18th, 2007.


RecentChanges · preferences
edit · history
Last edited May 18, 2007 6:13 am GMT (diff)