Why are string identifiers used to access resource data?

I'm working a project to replace a Resource Management system (QuickTime Resource Manager on Mac and Windows) that has been deprecated and I have been using the current model that Qt uses where data is retrieved from the resource file using a string key.

For example, I may have an image in my resource file, "HungryBear.png" stored in my resource file. Qt, and my proposed system, would get it in a way depicted by the psuedocode:

image = GetImageResource("BearPlugin/Images/HungryBear.png");

It is clear at that point what that image is, and where it can be found.

In our current system, we use numbers. The problems with numbers is that one has to hunt down the resource file (there can be many) to find out what image (or resource) it is.

An example of this:

oldActiveResourceFile = GetActiveResourceFile(); // think of a stack of resource files

SetActiveResourceFile("BearPlugin");

image = GetImageResource(1);

// Perhaps other resources are retrieved and other functions called
// Possibly introduce problems by calling functions that change "Active Resource File"

SetActiveResourceFile(oldActiveResourceFile);

The first method is what I have seen in current systems that access resource file data. I've been told that C# and Java uses it, I know that they do for string key-value pairs, etc.

However, a peer of mine has expressed concern about changing the current system of using these number IDs for the string ids that I'm proposing. There seem to be many benefits and they fix many of the issues we've had with the current system. I want to have supporting documentation that the proposed system is better and desirable, so my question is this:

Do you know of any research or discussion that demonstrates that using a string identifier (hierarchical) in code is better than using an arbitrary number?

NOTES

1. I plan on using a zip file (possibly uncompressed) to contain the data files.
2. We have a application-plugin environment. The application and each plugin can have its own resourc开发者_StackOverflowe files. Plugins may be able to access resource data in the application's resource file.

3. Here are some requirements that have been considered and I believe met:

   • Software Developers shall be able to uniquely identify resources.
   • Software Developers shall be able to name resources with meaningful names.
   • Resources shall be associated with the parts of the application that need them.
   • Localizers shall be able to easily identify resource files that have changed.
   • Localizers shall be able to use their own tools to modify resource files.
   • Customers shall be alerted in the event that the functionality they are using relies on deprecated calls.

The main drawbacks to using numerical resource IDs are discoverability (figuring out what resource 1234 is) and maintaining uniqueness of the IDs as you add more over time in large applications.

The main drawback to using string names for resource IDs is that strings take up more memory at runtime. The .NET pattern for resources, for example, uses string names, and those string names tag along in the executable file at runtime.

String names are easy to keep unique and self-documenting across large applications and years of revisions (using hierarchical paths as in your example), but the benefit is really only for human convenience. It would be nice if those strings could be boiled down to integer IDs for the final executable binary, since the resource pool is immutable at that point and the CPU would actually prefer integer IDs. .NET doesn't work this way, but other platforms could.

76 87 123 84

vs

OpenWithNumericExample
OfferStringsInComparison
CommentOnGreaterReadabilityOfLatter
PointOutGreatDebuggingAdvantageOfLatter

That sort of breaks the separation of content from code. A res file is easier to change than N code files that contain hardcoded references to images. Maybe consider putting those strings in a Settings object that gets [de]serialized on load/unload.

It is simply a lot more practical, the names can be self documenting.

Resourcebundles are often used in internationalisation efforts. And there are tools which scan the source files, change all strings to function calls to get a like-named resource and generate the default mapping.

In the code you can still read what is being output in the default langauge.

In the translation bundle you map the default language to the targetted languange.

This facilitates this process considerably.