Re: wish for 5.2

[Jerome Vuarand <jerome.vuarand@...>]

2009/2/12 Hans van der Meer <H.vanderMeer@uva.nl>:
> On 12 feb 2009, at 21:18, Peter Cawley wrote:
>>> (1) extension of the luaL-check.. and luaL_opt.. repertoire with
>>> functions
>>> for the retrieval of booleans.
>>
>> The behaviour of such a function is very dependant upon the user's
>> requirements. Usually none,nil and nil always count as false, and
>> everything else is true, and hence lua_toboolean() does the job
>> without the need for an opt or check function. Having none or nil have
>> some other behaviour would be extremely counter-intuitive in most
>> cases.
>
> You are right of course on the interpretation of what is false and what is
> true. But I think the essention of a luaL_optboolean is that in the case of
> an absent argument the optional value (given on the call to luaL_optboolean)
> is returned. That would make luaL_optboolean different from lua_toboolean
> without violating the general definition of what is false and what is true.

I think that the very absence of these luaL_check*/opt* functions is
useful, because it makes people wondering why they are absent, and ask
about it (the question is frequent on the irc channel), and then many
people discover the fact that it's considered a good habit to accept
any value type as boolean (with the usual semantic none/nil/false is
false, rest is true). This is encouraging them to keep that semantic
in their code (and lua_toboolean is enough to implement that
semantic).

If these missing functions were added, many module authors would use
them, and thus unwillingly force their users to use actual booleans
when calling their functions.

That reasoning may be too meta though :-)

>>> (2) at least one extra table slot on userdata.
>>
>> That would be the userdata's environment table -
>> http://www.lua.org/manual/5.1/manual.html#lua_setfenv
>
>
> Did I really miss this easy solution? I am afraid it looks that way! First
> thing in the morning will be to investigate its application to the module
> under development. Thanks!

Yes, userdata have two associated tables, environment and metatable.
You can use one for class data, the other for instance data. Since
comparison metamethods are only called if the two userdata have the
same, it seems easier to use the metatable for class data, and the
environment for instance data, but you can do the opposite.