The reason I do not speak about configuration is because I see no additional value in this abstraction. The reason I do not distinguish between code and data is because I see no value of doing so. May I ask you, why we should care whether something we load at runtime is "code" or "data"?
I don't think it makes any sense seperating code from the data it operates on. One of the most important ideas behind OOP is *not* to separate code from data, but treat them as a unit.
This argument amounts to saying we should always use established terminology even if our requirements are different. I disagree. Yes, using another terminology means the user has to learn another word. But it also means the user won't misinterpret the capabilites of a script because it is referred to as "configuration". I prefer an obstacle in plain sight to a hidden one anytime.Will you be the one explaining that to our users?
And yes, I think it's no big deal to explain this to a user:
Q: "Where are the configuration files of AA? I want to change something."
A: "The behavior of armagetron is defined by scripts, check your scripts folder and see the wiki for a breakdown of what can be adjusted in which script."
But you propose to travel twice as far as neccessary: You build an API to access script objects from C++ and build an API to access C++ objects from script. Isn't it cheaper to build just the former?Sure it's a lot of work, but that's not because of the chosen way, it's because of the long distance. There is no magic wand that can link script and C++, even SWIG needs some help, especially if you do crazy things on the C++ side.