Christopher wrote:What does "some overhead" mean? Do you have an actual performance problem directly attributable to this? Perhaps using APC, if you don't already, might be a better solution that recoding?
Fair question. We have bumped into pages where we are running out of memory, as a combination of many things on the page. The languages just seemed an easy target that could improve things on every page. Most impact for the least work kind of issue.
APC is definitely an improvement, and we already encourage its use by admins. Unfortunately, some don't have that choice, and we work to optimize the game to work even without it.
As to avoiding recoding, that isn't an option. It is incredibly outdated code (we've uncovered hacks that fix PHP issues from before 4.2, that are no longer valid, for example), and that still rely on a register_globals style auto-import. We want to improve the game to add features, but to do so, we simply have to recode large portions of it to get beyond the design restrictions of the past.
Since we're already recoding, I figured it was time to rethink key design decisions (like the language design).
Christopher wrote:The Phoenix wrote:We're pondering storing it in a database, but during that process, it occurs to me that maybe languages need to be an object. A language object, and then english would extend that. I think the language object would only have a getter and a setter (?)
Am I on the right track here, in terms of design, or am I just seeing an object because I'm tired of staring at 30k lines of procedural-only code?
Not sure what "languages need to be an object" means. Obviously you want to abstract the language part so that you don't have code dealing with that spread throughout the game. There are a number of solutions to the problem of providing multi-language support -- each with different trade-offs.
Today, the "interface" for a programmer on the game wanting to get output that is translated to match the users desire is a variable. (That the variable is actually in the global scope is just insult to injury). I'm trying to determine if that is a bad design choice, and if instead the interface should actually be an object called "language", with a property of each language variable.
The entire game already uses this "import all language variables, declare a global variable, and echo it" coding throughout the game, so there isn't really a way to avoid code spread throughout the game. I'm just trying to develop a solid alternative that doesn't require 1400 global variables for a page that will only use 5.
I could do that with just a simple function that does a look-up for a variable name in a db table, or I could make it an object. I'm hoping for advice on which is a good choice (or if there is another choice I'm not thinking of).