Re: __call?

[Gustavo Niemeyer <niemeyer@...>]

> 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

IMO, changing lua_isfunction is a bad thing. The right way to fix that
would be to introduce "lua_iscallable", or "lua_tofunction", or
something similar.

> 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.

It looks to me like a "doctor it hurts" case. If the code is supposed
to detect callability changes, just test it multiple times. If the
code is supposed to store a value which should always be callable, don't
turn it in something not callable or it will throw an error.

> 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
[...]

Notice that lua_tostring doesn't check for the __tostring member. It's
the "tostring()" Lua function that checks. Have a look at the luaB_print
and luaB_tostring implementations.

-- 
Gustavo Niemeyer
http://niemeyer.net