Re: Problems with compat-5.1 release 3

[Diego Nehab <diego@...>]

Hi,

> > Besides, the fact that this __index field is left behind is an unwanted
> > artifact. I trully believe it should be removed even if you don't plan
> > to use "mymodule.error" or the like.  After all, the line
> >
> >     c = socket.socket.socket.socket.socket.tcp()
> >
> > is ridiculous. :)
>
> It would be really great to overcome this, but I'm afraid that I must have
> missed something. Do you propose to set __index of module metatable to
> nil? Won't this avoid the access to global variables by module functions?

Yes, that is what I mean. If you want to use global variables, save them
to locals before removing the __index metatable. That's why the "base"
module was in compat-5.1.lua. Since it is not going to be in Lua 5.1 (it
looks like, at least), I suggest you do something like

    local base = _G

instead. Then you can use base.print, base.tonumber etc. All other
functions have their own nice little namespaces.

The only reason I am not setting this to nil in LuaSocket yet is because
I don't have _M in the namespace. That will be fixed in release 4. 
Using getfenv looked ugly.

> Additionally, in the case that the module writer decides to change the
> __index for the module like you suggested earlier, if I set it to nil then
> the particular semantics previously defined by __index won't work anymore
> in any situation. So why bother to use rawset only at the module loading
> scenario?

Because the developer can change __index to be anything, not just nil as
I suggested! That's what I was talking about. Having __index point to _G
is not useful. But have it point to something else might be very
interesting. I don't want to kill that possibility.

> One thing is that the code below works just like I expected it to do.
[...]

Will check what Roberto has been up to before releasing the next
Compat-5.1.

> Another little silly difference is the base module for Lua basic
> functions. These little differences may not cause many problems now, but
> some developers may be a little disappointed if they find out that their
> Lua-5.0.2+Compat-5.1 compliant modules does not fit properly to the
> package model in Lua 5.1. At least, I did! :o)

Tell these developers not to be so hard on us. We don't control Lua 5.1
and sometimes whatever we agree upon with the Lua team just doesn't make
it into the next work version. It's a moving target. It's not out yet.

[]s,
Diego.