Multi file programming

[bobbyjones]

zorg that is what I am saying he should pass the map to the player. You were suggesting that the player could access it with no passing.

Schemantic difference between passing one module to another via require/load and passing through some function exported from player; in any case, it's possible however we want to call it Even if i did overcomplicate things, which wasn't my intention!

i dont believe you can pass through require either.

[zorg]

You're right, but you can give parameters if what you require returns a functon instead of a table; anyway, I'll add it as a test to my soon-to-be "What can you do with löve (that's naughty)" git repo

[Zarty55]

In my opinion working with require is much better. You can define a library in a file anywhere and require it locally in any other file. I personally don't like polluting the global environment with things that I won't use in every file. It's also much more organized and easier to read.

[zorg]

The one thing i dislike about using require -everywhere- is that in a way, it does pollute one place, the package.loaded table. By pollute, i mean that if a library itself needs to load files from its folder, i'd rather if that part wasn't exposed inside package.loaded for encapsulation reasons; simply doing a local whatever = lfs.load("dir/file.ext")() executes the loaded chunk into the whatever local variable, but it won't show up in package.loaded, since our package is the one we did require, but not its sub-files that it may or may not load.

[Zarty55]

The one thing i dislike about using require -everywhere- is that in a way, it does pollute one place, the package.loaded table. By pollute, i mean that if a library itself needs to load files from its folder, i'd rather if that part wasn't exposed inside package.loaded for encapsulation reasons; simply doing a local whatever = lfs.load("dir/file.ext")() executes the loaded chunk into the whatever local variable, but it won't show up in package.loaded, since our package is the one we did require, but not its sub-files that it may or may not load.

But that's the good part about require. It manages itself for you. I'm not sure what you mean by polluting package.loaded. Can you give me an example?

[zorg]

Yes.
Let's say you have a camera+viewport library. You require it. package.loaded.<libraryname> will hold the library.
Now, inside the internals of the library, somewhere, due to organizing code, the library coder used require to put the camera and viewport files into the main one, where he exposes/exports functionality to your game. Since those files were also required, you now have package.loaded.<librarycamerafilename> and package.loaded.<libraryviewportname> also. Kind of a forced example, but the fact is, the library programmer most likely wants the user to access stuff only from the main file of the library, and not directly, which might cause unforeseen errors, so they should have used lfs.load instead of require.
require does manage required files in the way that if you already required something, it won't reload it from disk (though this too can have its issues with live code reloading, for example...); but it should not manage normally non-public parts of a library.

Edit: Apparently require does use the full module name, as in keys being "lib1.util" and "lib2.util", if both libs would require their own util.lua. Sorry, i was wrong.

[Zarty55]

Yes.
Let's say you have a camera+viewport library. You require it. package.loaded.<libraryname> will hold the library.
Now, inside the internals of the library, somewhere, due to organizing code, the library coder used require to put the camera and viewport files into the main one, where he exposes/exports functionality to your game. Since those files were also required, you now have package.loaded.<librarycamerafilename> and package.loaded.<libraryviewportname> also. Kind of a forced example, but the fact is, the library programmer most likely wants the user to access stuff only from the main file of the library, and not directly, which might cause unforeseen errors, so they should have used lfs.load instead of require.
require does manage required files in the way that if you already required something, it won't reload it from disk (though this too can have its issues with live code reloading, for example...); but it should not manage normally non-public parts of a library.

Edit: Apparently require does use the full module name, as in keys being "lib1.util" and "lib2.util", if both libs would require their own util.lua. Sorry, i was wrong.

Oh ok. Yeah, no problem. I think you will enjoy more using require now :p