lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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

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

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.