Internal Stuff
==============

This is a developer document, not a user document.  You probably don't
need to read this.


Private/Internal Variables
--------------------------

Everything that the user shouldn't dabble with starts with '_'.
For example 'pd._constructor', 'self._object', etc.  This includes
everything that messes with pointers, for many purposes have a
stub: function f(self, ...) return _f(self._object, ...) end

Things that the user can use shouldn't start with '_'.

Everything in pdlua should be in the 'pd' global table.


Table Indices
-------------

As per Lua conventions, Lua tables start at index 1.  See:

lua.c/pdlua_pushatomtable()  (C->Lua)
lua.c/pdlua_popatomtable()   (Lua->C) (makes additional assumptions)


Inlet/Outlet Numbers
--------------------

C   code uses 0,1,...
Lua code uses 1,2,...

Translations are performed in:

lua.c/pdlua_dispatch() (C->Lua)
lua.c/pdlua_outlet()   (Lua->C)


Pointers
--------

Pointers are all Light User Data values.  This means there is no type 
safety, make sure you're using the right pointers!

pd._classes    :: string   => Lua object (class prototypes)
object._class  :: t_class*

pd._objects    :: t_pdlua* => Lua object (object instances)
object._object :: t_pdlua*

pd._clocks     :: t_clock* => Lua object (clock instances)
clock._clock   :: t_clock*

pdtable._array :: PDLUA_ARRAY_ELEM*

Pointer atoms are also stored as Light User Data.  It's possible for
things to crash if they are used/stored/etc, as far as I understand the 
way Pd uses them.


Architecture Issues
-------------------

:initialize() is called before the object is created.
:postinitialize() is called after the object is created.


Other Issues
------------

"#t does not invoke the __len metamethod when t is a table."
See end of: http://lua-users.org/wiki/GeneralizedPairsAndIpairs

This means pd.Table will remain ugly, with :length() :set() :get()