Cytoscape WikiGaryBader -9/30/05 - why do the setters take basic types e.g. double and the getters return Object types e.g. Double? Would it be simpler for the user to expect one or the other consistently?
EthanCerami -9/30/05 - Originally, I had the getters/setters use the same primitive types, e.g. boolean, double, String, etc. But, this becomes a problem for the getters. For example, if you request a boolean, but there is no value for this id/attributeName pair, what do you return? false? Hence, I switched to using wrappers. That way, if there is no id/attributeName pair, you get back a null. I then decided to keep the setters with primitive types, primarily for programmer convenience.
IlianaAvila -9/30/05 - I think that the setters should take wrapper classes instead of primitives, for consistency. It is not that hard to type "new Double(d)" for programmers 
NeriusLandys -9/30/05 - Originally I wanted to have a method for each type of attribute (String, Double, etc.). But this adds a lot of methods. What is worse is that for multidimensional data the number of permutations for data types grows very quickly, so for multidimentional data we are basically forced to use Object.
EthanCerami - 10/1/05 - OK, Gary and Iliana are probably right on this one. Let's modify all getters and setters to take wrapper objects.
EthanCerami - 10/2/05 - Subgroup (Ethan, Iliana and Nerius) all agree to work with wrapper objects only. Ethan to modify interface.
JamesMcIninch - 10/6/05 - More specifically, I'd simply like to see the key be a String and the value be an Object (or, possibly an array of Objects). This would greatly simplify the interface and implementation in general. You can explicitly define what happens for specific types of objects, where necessary, otherwise the implementation would be wide open. This is how native Java deals with a very general case like this.
EthanCerami - 10/7/05 - This raises a good point, which is not explicitly stated in the RFC. One of the main differences between GraphObjAttributes and CyAttibutes is that GraphObjAttributes can store arbitrary objects, whereas CyAttributes is restricted to Boolean, Integer, Double and String. We made this design decision for several reasons (and, I will include these in the javadocs):
- Plugin Intercommunication - we want to enable plugins to share attribute data without having to agree to use some custom data structure or custom Java object ahead of time.
Attribute import/export - we want to be able the complete import/export of all attributes (and, we don't want to use Java serialization.) Right now, if you store an arbitrary object in GraphObjAttributes, and then save node node attributes, these arbitrary objects are not written out, and this data is lost.