RE: __call?

[virgil@... (Virgil Smith)]

> As an interesting point, it should be noticed
> that callable objects unfortunately are not
> real functions, and any code that tests for a
> function type fails to detect the callable
> object. For example, table.foreach() can't
> receive a callable object as the second
> argument.

My $0.02 -- followed by a couple questions...

So, this is a bug-report for lua_isfunction more or less, since callable
objects <should> be compatible with functions.  This would fully enable C++
"functor" style capabilities (i.e. state tracking).

Unfortunately, whether changing lua_isfunction is a "good" thing is not 100%
straight forward.  At least one reason for this is that (AFAIK) Lua types
are static, which is to say that a value cannot have it's type changed after
creation (of course a variable can have a value of a different type assigned
to it, but this is a different statement).  However, the classification of
an object as a "callable object" (i.e. of some type compatible, for the
purposes of this discussion, with functions), depends on an entry in the
object's metatable (which can change).  The problem with that dynamism is
that a code construct that saves a "copy" of such a value (after checking it
for calling capability) for later use, may throw an error during that later
use if the object's metatable is modified between the time of the safety
check and the actual use (i.e. calling) of the object.

Naturally, lua_isstring, lua_isnumber, and lua_istable suffer from similar
issues.  The easiest of these to understand is lua_isstring, because of the
behavior of tostring checking for a _tostring [sp] member of the object's
metatable.  While AFAIK no such metatable member exists for numbers or
tables they are conceptually similar and such a metatable member could be
put forth as a standard.

A related issue is the question of the distinction between userdatas and
tables.  Several people have suggested the use of a userdata acting as a
proxy for a table in order to work around the (in my opinion) bug/flaw in
Lua that _gc metamethods are not called for tables.  While this does work,
it, unfortunately, breaks the objects classification as a table (lua_istable
will return false).  Furthermore, next will not function on such an object.
Personally, I think that the deficiency with next and proxy tables should be
resolved by the addition of a standard metamethod for "next behavior", but
others may have better ideas.

----
So, does anyone have suggestions for type "emulation"/compatibility
flexibility in Lua?

To the Lua authors, are there any plans for changes in 5.1 or later to
address these issues?