Local or global namespace - best practice...

[bedges]

I have a rather large array, multi-dimensional, which is only likely to be used once or twice, and the variables in which can basically be thrown away once used. However, the entire array needs to be available for use by at least two scripts.

The question: is it better practice to declare the multidimensional array locally within each script which uses it and have the values gone from memory when the scripts end, or declare the array once in the global namespace, even though it's used so seldom?

[Spooner]

If you have the data in a pre-compiled SQF then that is a bit wasteful since the parse-tree will contain a complete copy of the array and then, each time you want to use it, it will have to be constructed anew. I don't know how big you mean by "rather large", but it might well not be enough to really matter.

I have to do something similar in SPON Dynamic Terrain. I have 100k-1mb file which is just one big 2D array of height-map values. The file is literally just an array, without any code (and is auto-generated outside the game from a regular XYZ file). There is a pause while the file is loaded (perhaps I should split the file into smaller parts?). I use it to mould the initial terrain and then, as it is local, it disappears when the script is completed.

I use loadFile, rather than preprocessFilein this case, since I know the contents of the file is mechanically generated, so I know what is in it and I don't need preprocessing. Not actually tested whether that makes any difference, but every little helps:

Code: (heightMap.sqf (just an array)) [Select]

[[0, 123, 11, 123, -12,...], ...]


Code: [Select]

_heightMap = call compile loadFile "heightMap.sqf";


[Worldeater]

Hmm, that's not a technical but a religious question.

The pragmatic approach:
You use a global variable. That's what they are for. You don't care if your code becomes unreadable over time. It's your code after all and if it was hard to write, it should be hard to read!

The dogmatic approach:
You avoid global variables at all costs. Every child knows they are evil and smell of sulfur! You don't mind code duplication and/or creating totally absurd constructs to follow the "true way".

[Spooner]

I think that Bedge's definition of what a large structure is not the same as mine, so I was giving a slightly different solution than that requested. I considered a question regarding a "large" structure to be more about whether that structure should be held in memory once (stored in a precompiled function) or not at all (stored in a file function). From what Bedges said in IM, his data could quite happily be stored in memory without any adverse effect (in which case, the global/local question becomes the only relevant one).

Worldeater, I'm sorry but your definitions are wrong. Pragmatism is doing what is best in a given situation given its merits, which may well be the same choice as a dogma in specific instances (dogmas are often "right" since they are an attempt at a correct answer that will be correct in all cases, but since they don't allow for special circumstances, they are also often "wrong").

The unstructured approach: Use globals since they are "easier" and you never need to decide whether to use globals, locals or consider scope or namespaces.
The pragmatic approach: Always use local variables unless you need them to be global.
The dogmatic approach: Never, ever use globals (this is impossible natively in SQF, unless you don't require inter-script or network data transfer, but you can effectively simulate it using a closure).