views:

102

answers:

4

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 desireable, 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 resource 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.
A: 

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.

Novikov
The content is already separated from the code in resource files. These files can be edited separately before or during the execution of the code. What I am looking for is any supporting material that promotes string identifiers over arbitrary identifers referecing an indexed resource file.
Lyndsey Ferguson
I'm sorry I misinterpreted the "a/b/c.png" pattern as a filepath rather than a reference to a resource.
Novikov
No problem. I'm using the file path paradigm because our developers will understand it and, its actually accurate (relative to the containing resource file). The resource file(s) will be zip files with the resource files embedded inside of them.
Lyndsey Ferguson
A: 

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.

Peter Tillemans
That's interesting. I can see it being useful for string resource management and may make it part of the system. However, this response doesn't actually help me support my proposal of to access abitrary resources using a meaningful string identifier.
Lyndsey Ferguson
Do not forget that often icons, images, sound clips etc... must be internationalised. It would be confusing to use multiple mapping systems.
Peter Tillemans
Thanks, I haven't forgotten them. I plan on accessing them by the name. The data that is contained at that referred-to-name will be localizable.
Lyndsey Ferguson
+2  A: 

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.

dthorpe
Actually, in our case, the resources will be mutable during execution of the application. Our localizers (external to company) will be able to modify the resources, for example in a dialog window, and be able to close and re-open the dialog window to see their changes.
Lyndsey Ferguson
The resource *content* is mutable by translators, but the resource *IDs* are not mutable once they have been compiled into the exectuable. In a resource compiler scenario, the string names of the resources can still be shown to translators even though the bulky strings have been reduced to compile-time integers by the exe compilation process.
dthorpe
I'm not sure I follow. Would a checksum be created in the code and the resource system that looks for the resource would do ?something? to look up the resource? Create checksums by parsing the resource file on launch?
Lyndsey Ferguson
No, a checksum can't guarantee uniqueness (unless it's very large). Here's how resource compiling could work (but doesn't in .NET): As part of the app build process, the source code compiler recognizes strings used as resource identifiers and builds a hash table of the unique resource strings it finds in the code. Number each string in the hash table to create unique integer resource IDs. Compile the int IDs into the exe and the resource table. Output the string-int map to a file so it can be used to display the resource names to translators later.
dthorpe
This seems to be the best answer.
Lyndsey Ferguson
+2  A: 
76 87 123 84

vs

OpenWithNumericExample
OfferStringsInComparison
CommentOnGreaterReadabilityOfLatter
PointOutGreatDebuggingAdvantageOfLatter
Jon Hanna