RE: __call?

[virgil@... (Virgil Smith)]

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

Off hand, I'd agree with you, but the question is one of consistency.  Since
lua_isstring makes a "compatibility" statement rather than a literal "the
type of this is string" statement then lua_isfunction should behave
similarly.  Of course a "function compatibility" statement is a stronger
statement than "iscallable", because you can do more with a function than
just call it IIRC (manipulation of upvalues anyone?).


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

Yes, in practice the solution is obvious, however, from a language
design/elegance/clarity standpoint I see it as an issue.  Specifically, what
I see as an issue is that user defined types are not static in Lua.  Of
course I think this is more a matter of how <I> think, and not a question of
a problem with Lua.
Another way of looking at this is to contrast Class Oriented Programming
with true Object Oriented Programming (think of contrasting C++ with say,
Smalltalk).  Lua is clearly Object Oriented, not Class Oriented, however, by
sharing metatables, Lua allows Class Oriented styles of operations.

So, um, yeah your right. I just need to accept (metaphorically speaking) not
only that its possible for a specific "horse" to change into a dog, but that
at any point the definition of what a "horse" is, may change.  :P

> 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.
Um, yep.  Thanks for the correction.

--
Gustavo Niemeyer
http://niemeyer.net