Well, Appearance.class.getName() actually does return the string “com.xith3d.scenegraph.Appearance”. Of course, since setNodeComponent(String key, NodeComponent component) takes a String as a key, there’s nothing stopping a user from supplying any string he so desires.
In general, I think class.getName() is cleaner than hard-coding the string: it will cause compile errors if you mistype it, and it need not be changed if the class is ever refactored into a different package (not that I expect that to ever happen, but you never know).
I suppose I could, though personally I’m a bit happier using Strings as keys rather than Class objects as keys. I sort of feel that String equality testing behaves in a somewhat more predictable way than Class equality testing. Plus I think having strings as keys is more adaptable to strange cases. For example, suppose I were to write a Node object that had two separate Appearance member variables. With strings as keys, I could just do this:
public void setAppearance1(Appearance appearance) {
setNodeComponent(Appearance.class.getName() + "_1", appearance);
}
public void setAppearance2(Appearance appearance) {
setNodeComponent(Appearance.class.getName() + "_2", appearance);
}
In fact, Appearance itself contains an arbitrarily sized array of TextureUnitState objects. I’m still trying to figure out the best way to approach this one, but something similar to the above is certainly possible. I’m also contemplating creating a NodeComponentArray wrapper class that is itself a child of NodeComponent, and simply contains an aribtrarily sized array of other NodeComponent objects.
I have to say, I think having setNodeComponent() only take a single argument is a patently bad idea. The problem is, if I’m writing a child class of Node and I want to use this functionality to set node components, how do I know what to supply as the key for relevant getter? I don’t. By forcing the user to supply the key in the setter, I can gaurentee that said user will know exactly what to supply in the getter. It’s best to keep the definition of the key localized in a single class.
Paul
