Re: Unified tables and userdata

[Rici Lake <lua@...>]

On 14-Oct-04, at 5:41 PM, Dimitris Papavasiliou wrote:

> The __index
> behavior you're referring to can probably implemented with something 
> like
> this:
>
> if (!strcmp(lua_tostring(l, 2), "foo")) {
>     ...
> } else if (!strcmp(lua_tostring(l, 2), "bar")) {
>     ...
> } else
>  lua_rawget(l, 1);
>
> where foo and bar are "special" values and everything else isn't.  
> This code
> is pretty simple and logical and also note that you can still use the 
> foo and
> bar table fields to store useful data.

If you are coding a lua_userdata metamethod, __index and __newindex are 
precisely get and set, so I don't see what you are complaining about. 
The "only applies to nil entries" only applies to native Lua tables.


> Isn't pairs implemented on top of next?  lua_next() is the only 
> function
> available in the API.

That is, imho, irrelevant. Having coded quite a number of iterators, 
and for
the reasons I mentioned earlier, I believe that it is more convenient 
to use
a __pairs metamethod to implement the pairs() standard library call.

Furthermore, pairs is not exactly "implemented on top of next"; it 
returns a
closure to perform the next() function. It should not be necessary to 
do a
metatable lookup on every iteration of a loop; the closure only needs 
to be
generated once.

You can read more in the mailing list archives if you care to.

> Why do you want tables and userdata to be different concepts? In your 
> approach
> you unify tables and userdata but still keep simple tables around.

Tastes differ, I suppose. Not all my userdatas mimic tables, but even 
the ones
that don't sometimes need to store Lua objects. (Function closures 
aren't tables
either, but they are very useful objects.)

Anyway, just my S/.02 worth.