commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [beanutils] Indexed/Mapped DynaProperty
Date Sun, 15 Feb 2004 00:25:56 GMT
Quoting Niall Pemberton <>:

> 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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message