Ok, I kinda assumed you were talking about a version that already existed, so I just misread 5.10 as 5.1.0.bartbes wrote:Because 5.10 is a later version than 5.2?
cross version compatible module definition
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: cross version compatible module definition
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: cross version compatible module definition
Howdy, I will do my best.Inny wrote:The search form didn't answer my question so I'll start a thread about it, and I'm guessing Kikito is the one I'd like to answer it
What makes you think that code is any better than just setting and returning the module table? Why do you think you need to manipulate the module's environment at all?Inny wrote:The feature in particular I'm after is simulating _ENV's safety. I think this it the way to go:
Code: Select all
local module = function(_ENV) __ = {} ... return __ end local environment = setmetatable({}, {__index = _G}) if setfenv then setfenv(module, environment) end return module(environment)
I strongly disagree with both parts of this assessment.nobody wrote:No. Quite a few people define setfenv / getfenv as compatibility functions [...] If you need to check the version, check _VERSION !Inny wrote:Is checking for setfenv enough to discover 5.1?
First, I think testing for the existence of setfenv is just enough. If someone has a non-standard definition of setfenv, there are two possible scenarios: that their own setfenv is compatible with the standard one (maybe doing something extra on the side, like printing in a log), or that it doesn't (i.e. they have redefined it to be an empty function). In the first case, your code will work just fine if you just test for setfenv. In the second case, your code will never work. Even if you use _VERSION, and detect that you are in 5.1, when you try to use setfenv it will do nothing anyway.
On the other hand, I don't think that using the _VERSION string is a good idea. The browser world has told us again and again that it is not a good idea to check a string to deduce capabilities (at least if you want your code to be usable in the long run and you want to keep your sanity). Instead you would check for capabilities directly. That means doing if setfenv then ... or if type(setfenv)=='function' then ... if you want.
But the best option is not having the problem in the first place. I still don't know why you think you need to manipulate the module's environment in the first place, Inny.
When I write def I mean function.
Re: cross version compatible module definition
I mostly don't. Like for ascii.lua, there's nothing to sandbox. For the thing that I used as example for this thread, funky.lua, it's superfluous as I doubt I'd hit the 200 upvalues limit anywhere. So for right now, It just be nice to have an environment that's not _G, which I can apply strict.lua to and catch programming errors. Longer term, I may have a non-programmer writing code for me. That needs minimal sandboxing. Thus I guess the point of this thread was me asking what's just enough to catch rogue global vars and nothing more.Why do you think you need to manipulate the module's environment at all?
I do agree however, that well written modules shouldn't even need this or even think about it, so if anyone asked me what I recommend as a module definition, I answer with "return local module", and not python's file-implicit environments.
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: cross version compatible module definition
For that, I recommend Luacheck. Run it on every source file you want and it will warn you about implicit globals and a bunch of other stuff.Inny wrote:Thus I guess the point of this thread was me asking what's just enough to catch rogue global vars and nothing more.
When I write def I mean function.
Re: cross version compatible module definition
Awesome advice, thank you.kikito wrote:For that, I recommend Luacheck. Run it on every source file you want and it will warn you about implicit globals and a bunch of other stuff.
Who is online
Users browsing this forum: No registered users and 6 guests