Using Libraries

[Xgoff]

if it's a really trivial thing like a class lib (which i never use anyway) or vector lib, or if i only need a small subset of some gargantuan lib, then i usually write it myself. i find it a lot less annoying than trying to find/learn an existing one when i could just make the thing work exactly how i want it to, with as much or as little magic as i want.

if it's something i want to learn more about then i'll also write an implementation myself (as long as it's not obviously a huge undertaking); i never realized just how simple cloth simulation really is until i actually did it myself... it's less than 100 lines of code (granted this is with crappy euler integration, and no cool effects like tearing)! i figured these kinds of physical simulations would be really difficult to implement, but apparently not.

i'm sure as hell not going to try to write my own hardoncollider, though, because collision detection is boring and tedious and somebody else already did the work!

[Roland_Yonaba]

Funny that you mention that. It's totally on my TODO list for middleclass v3.0 (which I plan to release at some point this year).

Yup. And that will certainly imply to reconsider middleClass's plugins. Because most of them start with checking globals that middleClass creates.

Code: Select all

assert(Object~=nil and class~=nil, 'MiddleClass not detected. Please require it before requiring ...')

[kikito]

Yup. And that will certainly imply to reconsider middleClass's plugins. Because most of them start with checking globals that middleClass creates.
...

Thanks for pointing that out. Truth to be told, I never liked those conditionals anyway.

I was planning to do a poll to ask if anyone was against the "return one variable on require" move, but it seems pretty much anonymous. Good, that makes things simpler. Thanks for your feedback.

[coffee]

Inny talked about the "Return Local Module style" and I believe saw that approach used by some coders inclusive in kikito's libraries. I think is interesting all be local and make all private and only what we pretend be public. I suppose too besides "security" gains in globals cleaness and speed right?. Can I ask a quick (and lazy) question? Well I don't remember saw at same time the local return concept with entity:action() style of operator functions. Are they possible/advisable use nicely them both togheter or could have some inconvenient?

[Inny]

Inny talked about the "Return Local Module style" and I believe saw that approach used by some coders inclusive in kikito's libraries. I think is interesting all be local and make all private and only what we pretend be public. I suppose too besides "security" gains in globals cleaness and speed right?. Can I ask a quick (and lazy) question? Well I don't remember saw at same time the local return concept with entity:action() style of operator functions. Are they possible/advisable use nicely them both togheter or could have some inconvenient?

Return Local Modules are encouraged because they're backwards compatible with 5.1. There's a few of ways to do them, which I'll show here:

Code: Select all

local M = {}
function M.doThing() --[[ something here ]] end
return M

Code: Select all

-- This one is very common in Love, and similar to a javascript style
local function doThing() --[[something here ]] end
return {
  doThing = doThing
}

Code: Select all

local M = {}
return setmetatable(M, {
  __call function(...) --[[ now the module is both a table and a function ]] end
})

As for using the : sugar syntax with modules, yeah you can do that. I myself actually do that with any modules that have some internal state associated with it. My reasoning is that its behaving like a Singleton, and being Lua and all I'm free to skip some unreadable mess like this: Module.instance():method(), and just go straight for Module:method().

[coffee]

As for using the : sugar syntax with modules, yeah you can do that. I myself actually do that with any modules that have some internal state associated with it. My reasoning is that its behaving like a Singleton, and being Lua and all I'm free to skip some unreadable mess like this: Module.instance():method(), and just go straight for Module:method().

Nice to know that. I will then start convert to use local returns since all my code and libs are full of syntax sugar. Thank you also for code tips . The principle is actually simple and I had saw it also explained in what Lua Pil call "Module Definition" http://lua-users.org/wiki/ModuleDefinition

[Inny]

As for using the : sugar syntax with modules, yeah you can do that. I myself actually do that with any modules that have some internal state associated with it. My reasoning is that its behaving like a Singleton, and being Lua and all I'm free to skip some unreadable mess like this: Module.instance():method(), and just go straight for Module:method().

Nice to know that. I will then start convert to use local returns since all my code and libs are full of syntax sugar. Thank you also for code tips . The principle is actually simple and I had saw it also explained in what Lua Pil call "Module Definition" http://lua-users.org/wiki/ModuleDefinition

Just for completeness, I don't use the Return Local Module style for things I consider Game-Specific code. Like this module here: https://github.com/inmatarian/artsyjump ... r/util.lua
If I were to bundle this into a package that others might use, then I would, but since these functions were tweaked specifically for this game, it's easier to jam it right into _G.

If and when we get 5.2, my personal style will probably change to a style that manipulates local _ENV, but only for organization. It'll have the same intentions as before.