Quoting Niall Pemberton <[EMAIL PROTECTED]>: > I agree it could be read that way, with the word "simple" implying that. But > then the same author (Craig McClanahan) also wrote the standard > BasicDynaBean implementation - it has a single HashMap storing all values - > simple, indexed and mapped. > > The get(property) does.... > return values.get(name) > > The get(property, index) does either .... > return ((List)values.get(name)).get(index) > or.... > return Array.get(values.get(name), index) > > The get(name, key) does.... > return ((Map)values.get(name)).get(key) > > And it works perfectly well in BasicDynaBean (not throwing an > IllegalArgumentException) if you do > set(name, List) > (List)get(name) > get(name, index) > set(name, index) >
These are all intended behaviors for BasicDynaBean. (Note that the isIndexed() and isMapped() methods were added to DynaProperty later on, which is why BasicDynaBean doesn't pay any attention to them). In the documentation of the DynaBean interface itself, I wanted to be less stringent about defining the behavior requirements of the underlying implementation classes, because it was not clear to me that I knew all the possible use cases. This is similar in spirit to the fact that things like java.util.List and java.util.Map define some fundamental behavior, but there are often additional restrictions in the concrete implementation classes. > It would be wrong for an implementation to use Collection for its indexed > properties because, as you say, there is no concept of an index in the > Collection interface - so how could it determine which value to return for > get(name, index) or where to store it in set(name, index)? Maybe you could > bodge something together which would work for some Collection > implementations (e.g. List!!!!), but you couldn't gurantee it would work for > all, so it would be wrong. I think the same kind of logic goes for Robert's > argument that mapped properties could be backed by an Enumeration - there is > no concept of a key in an Enumeration, so how could an implemtation of > DynaBean be written based on that? I think most people would understand that > they are called "Mapped" properties because they are backed by a Map. > > If the other things you are asking for were added to the API, then I think > iterator(property) would be redundant. > > I think the reason that get(String name, String key) takes a String for the > key is that DynaBeans represent properties - and properties have String > names. A "mapped property" should be just that - a map containing properties > and therefore those properties should have String names. > That's it exactly. > Niall > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
