[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: __call?
- From: virgil@... (Virgil Smith)
- Date: Wed, 17 Dec 2003 11:25:50 -0600
> 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
Um, yep. Thanks for the correction.