RE: ANN: LuaState (A C++ Lua Wrapper and enhanced Lua 4.1 Distribution)

["Joshua Jensen" <jjensen@...>]

> Does this "unified methods" thing perform better than simply 
> using proto-style inheritence with a lua index tag method? 

There was a discussion about this by Edgar a while ago.  Do a search for
unified methods in the list for a much more detailed discussion.

Here is what I can tell you.  A unified method call is just as costly as
an indexed method call... That is:

Table:method()         and
Table->method()

Or

Table.method()        and
Table::method()

Cost about the same.  The unified method call is actually a touch faster
because there are no tag method checks.

A tag method invocation causes a full on Lua function call to happen,
with all associated state to be setup.  Depending on the tag method,
this may be no more overhead than the unified method call.  In the case
of the "index" tag method, which is most closely associated with the
unified method, you'll inherit at least one more function call... The
index tag method call itself to perform your faked inheritance.  Since
the unified method table can contain everything needed function-wise
(i.e. for deriving a new "class", I would duplicate the unified method
table in the base class and add the appropriate functions to the
duplicated table for the derived class), no index tag method is needed.

Since the unified methods use a different lookup syntax, the tag method
approach and the unified method approach may be intermingled as the user
desires.

Edgar has one more addition to Sol that LuaState didn't integrate.  In
Sol, tag methods are gone.  All former tag methods will call through the
unified methods table (I believe that's how it worked... If not, it's
the best approach.).   I think better consolidation of tag methods is an
excellent idea, and so did Edgar.  It removes all the special checking
in the code for tag methods and just calls the unified method interface.
When a method table is assigned to a new object, all tag methods defined
in the method table automatically become available to the new object.
Despite the benefits, I did not integrate this, because it would change
the core Lua semantics, and my desire was to add functionality, not
change or remove it.

So, in my opinion, the primary advantages become:

1) Memory savings.  One table full of functions per unique object type.
2) Faster than the "index" tag method.
3) Easy to understand.
4) Every object type can have unified method calls made to it.
5) All the advantages described by Edgar months ago.
6) And most importantly, the existing interface is not broken.  Unified
methods are only an addition to Lua.  If you don't use them, you don't
see them.

Thanks,
Josh

> 
> On Wed, Nov 07, 2001 at 10:33:40PM -0700, Joshua Jensen wrote:
> > Unified Methods
> > ===============
> > Unified methods are based heavily on Edgar Toernig's Sol 
> > implementation of unified methods (note: some text is taken 
> verbatim 
> > from the Sol documentation).
> > 
> > Every object in Lua has an attached method table.  For C++ 
> users, the 
> > method table is most similar to a v-table.  For Lua's simple types 
> > (nil, number, string, ustring, and function), there is one method 
> > table for all objects of the given type.  Table and 
> userdata objects 
> > have the ability to have method tables on a per object basis.
> > 
> > Unlike Edgar's Sol implementation, the colon operator for Lua's 
> > automatic self functions is not replaced with an alternate 
> > implementation.  This is done in an effort to keep LuaState 
> > functionality identical to the original Lua distribution.  Instead, 
> > two new function operators are introduced.  The pointer symbol (->) 
> > behaves like the colon operator, but it looks up the 
> function to call 
> > in the method table.  The second operator is the double colon 
> > operator, which behaves like the regular dot operator (no self is 
> > passed in).
> > 
> > The biggest advantage of unified methods is memory savings.  When 
> > dealing with many Lua objects (say, tables) of the same type, the 
> > functions don't have to be duplicated for each and every one. 
> > Significant amounts of memory may be saved by the use of the shared 
> > method table.