Love on a Higher Level

[Xcmd]

Okay, so... right now we have to call love directly a lot. This may be something that we have to wait for a much more future version to have, but it'd be just... just dandy if we didn't have to type love.whatever before everything within love. Kinda like how in pygame they make you include:

from pygame.locals import *

So you don't have to type pygame.this and pygame.that before you can get anything done. I know it's only a matter of five keystrokes, but I don't always remember to put them there and it can be a bit onerous to have to debug. Stuff like:

love.physics.newWorld( 1000, 1000)

Could easily be moved over to:

physics.newWorld( 1000, 1000)

as I'm sure Lua doesn't have a physics class inherently. Is there some way to do to this now? Or... y'know... do we have to deal with typing love alla time? Am I talking out of my ass here?

[Alex]

You can declare something like:

Code: Select all

physics = love.physics

At the top of your file which will let you call physics.somePhysicsFunction().

Alternately, if you don't ever want to type "love." you could use:

Code: Select all

for k, v in pairs(love) do
   _G[k] = v
end

Which adds every element of love to the global namespace, so that graphics.draw() (etc.) will work the same as love.graphics.draw().

[hdon]

I know it's only a matter of five keystrokes, but I don't always remember to put them there and it can be a bit onerous to have to debug.

Alex's suggestion is exactly right, but what you said about it only being five keystrokes isn't entirely accurate. IIRC, accessing members like this involves table lookups which slow down your app. If you're going to use a function more than a couple of times within a function, declare it a local. (This optimization may be nullified by closures, so be careful.)

[Star Crunch]

The closure will slow it down negligibly, but upvalues are still fast. This is a pretty decent summary: http://lua-users.org/lists/lua-l/2008-08/msg00089.html

If you expect your app to scale up, and / or play well with others, it's a good habit to favor locals anyhow. Otherwise you WILL stomp on variables with common names, and many headaches will be had.

If you go that route, you can enforce it by requiring "strict" (see attachment, from the "etc" folder of the LuaJIT folder lying around on my desktop), at the beginning of load() or the start of main.lua, and it will catch a lot of your typos / forgotten things. If you like having at least some prefix to your functions, you just cache that to a local, e.g.

Code: Select all

local table = table
local physics = love.physics

and then use it as before. This approach might be a little too much if you're not used to it, though.

[osuf oboys]

The closure will slow it down negligibly, but upvalues are still fast. This is a pretty decent summary: http://lua-users.org/lists/lua-l/2008-08/msg00089.html

If you expect your app to scale up, and / or play well with others, it's a good habit to favor locals anyhow. Otherwise you WILL stomp on variables with common names, and many headaches will be had.

If you go that route, you can enforce it by requiring "strict" (see attachment, from the "etc" folder of the LuaJIT folder lying around on my desktop), at the beginning of load() or the start of main.lua, and it will catch a lot of your typos / forgotten things. If you like having at least some prefix to your functions, you just cache that to a local, e.g.

Code: Select all

local table = table
local physics = love.physics

and then use it as before. This approach might be a little too much if you're not used to it, though.

Have you tested how much replacing all global variables with locals does in practice?

[Star Crunch]

Have you tested how much replacing all global variables with locals does in practice?

It's been a while since I started localizing a lot, and I think I adopted LuaJIT around that same time, so I can't really say. It's probably not a major concern unless you actually start seeing issues, and then the trouble spot might just be a tight loop or two. Keeping variables with the same name from stomping on each other is a more important concern, and maybe keeping functions from being overridden.

The free chapter in the Lua Gems book that recently came out has a bunch of good pointers: Lua Performance Tips