02 Feb, 2013, Telgar wrote in the 21st comment:
Votes: 0
plamzi said:
Telgar said:
I assure you it is, in exactly the environment you suggest, development and testing. And if you like to develop in a buggy dev environment, that is your business. I do not.

Nobody is advocating developing code in production. Apparently you've never heard of the term hotfix. And while I do know of many people who have been fired for not being able to do such a thing, I have yet to hear of a case where someone was fired for adding another option to a crisis manager's toolbox.

For a brief post, this one confuses a remarkable number of things. I can only assume it's an emotional reaction to misunderstanding Runter's (and my own) points. Just keep in mind that both Runter and I speak from experience. Maybe you have to live it to believe it.

Hopefully, you won't get to a point late in the game where you find out that there's something fundamentally dysfunctional about writing your entire code this way. That would be a huge waste. If you end up with functional code that's hard to maintain and that only you can understand, that's the lesser evil.

P. S. Also, the term "hotfix" doesn't mean what you think it means.

A valid interpretation. I woke up on the very wrong side of the bed and was welcomed into the morning by a screaming baby and a messy diaper change.
04 Feb, 2013, Telgar wrote in the 22nd comment:
Votes: 0
Runter said:
My point is that there's no dire need for this code to be in place. I was wholly okay with what you were saying until you said this is an exercise of necessity. Other readers may come here later thinking that's true.

Apologies for any offense incurred by my prior ranting.

I wholly meant for this idea and code to be served caveat emptor. The fact I have observed is, this pattern has had significantly beneficial impacts on my code. First, by requiring the complete encapsulation of all private data, modules are effectively isolated from each other. This is otherwise difficult to achieve in Javascript. Second, the module definitions become much cleaner. You are forced to write an import method, even if it is a dumb looking

(withThatModule(module) { ThatModule = module; })

Having to do that for a single module is not bad. Having to do so for dozens of modules is rather bizarre. Is that bad? At first I thought so. Now I do not. It makes you rethink your module system. It is a symptom of global namespace pollution creeping up, and a sign that … you need better stratification for your modules - probably now is the time to group into sub-modules. Do you really need to import TreeView and ListView when you could simply import Graphics, which has sub-modules Graphics.TreeView and Graphics.ListView?

The third thing this has done is undeniably increase my productivity. Reloading code into live game state is a hail-mary type play for production, but for development (to continue the divine analogy), it is a godsend. It has become an indispensable part of my workflow on this project, and while it isn't strictly necessary, it has saved countless hours of debugging for the relatively modest cost of forcing a (rather positive, modular) structure on my program. This is the sense I speak of when I describe it as necessary (if I ever had done that - I may have - dunno).

Lastly, this pattern has promoted, at least in my code base, the complete de-coupling of code and data. This was my intention from the beginning, but it introduces some strange effects. In particular, modules designed completely to serve data to other modules may have only "static" interfaces which return constants. Yet, those modules may have code to import and validate whatever data they serve. Without changing the code, those modules can be "reloaded", which consists of them making callouts to any other linked modules. Thus, this technique can even be applied safely in production. And yeah, I'll take on that controversial subject now. Internal details follow. If you don't care to know of my internals, I have no argument with that. However, don't take argument with my internals without at least some knowledge of them.

"Reloading" the Unicode module in production in this case would not actually involve any code change. It would simply be calling the various import and dependency functions to link the module into the running code. In the case of a reload of this type, it would consist of the Unicode module calling it's dependent modules (FileManager and SchemaManager), firstly to load the schema for Unicode tables, and secondly, to import all those tables from the specified import point. Although in the current system I have, the actual code is reloaded, there is no reason this needs to be done. The FileManager module tracks imported files and directories, and requires registration of an import name and method for any file. Thus, it can be told when a file is updated, and call out to invoke the import function for the active manager of that file. So I can reload data at will, and automatically update any live references to that data.

This has been an extremely beneficial pattern - now I have to implement an add/import/set function for all metadata in the game. Instead of being a chore, it actually protects my original design goal, the separation of code and game meta-data. Obviously this technique has the ability to be vastly mis-used, but in the proper context, it can be incredibly useful. I am not going to argue that context is live production. But I will say that if I can reload Unicode tables on a test instance, that, using the same code, and the same tables, is liable to produce exactly the same result in my live instance.

So, whether you like taking risks like that or not is up to you. In dev mode, for me, at least, it is necessary. In a live server, I would have severe reservations. But in a const only module… and yes, I do have such a thing, and it can be used, to a degree, safely.