commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From guillaume.tul...@fr.thalesgroup.com
Subject RE: [beanutils] Indexed/Mapped DynaProperty
Date Fri, 13 Feb 2004 14:06:05 GMT
You're right, get(name, index)/set(name, index) could not apply to
the Collection interface directly because the order is not guaranteed. 
But this means that Collection/Set are not treated by the current API 
in a neat way.

Instead of
 dynabean.set(name, ((Collection) dynabean.get(name)).add(value));

I'd prefer to write
 dynabean.add(name, value);

and then the iterator(property) would be useful to iterate on the
collection items like a isCollection() on a dynaproperty...
But maybe that's not the philosophy of the API and in this case 
I agree with you it would be redundant if the other methods would 
be added.

Guillaume.

-----Message d'origine-----
De : Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk]
Envoyé : vendredi 13 février 2004 11:54
À : Jakarta Commons Developers List
Objet : Re: [beanutils] Indexed/Mapped DynaProperty


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)

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.

Niall


----- Original Message ----- 
From: <guillaume.tuloup@fr.thalesgroup.com>
To: <commons-dev@jakarta.apache.org>
Sent: Friday, February 13, 2004 9:27 AM
Subject: RE: [beanutils] Indexed/Mapped DynaProperty


I'd like to add some remarks/questions:

- in fact, the javadoc for the method DynaBean#get(String name) says
"Return the value of a simple property with the specified name" and
I though it was not allowed to call it on an indexed/mapped property
without throwing an IllegalArgumentException

- indexed properties always reference array or List types but what for
Collection in a more general way ? Is there a restriction with this
interface (except the fact that a collection does not always contain
indexed element) ? Your solution would suit me perfectly if it could
be extended to the Collection type.

- I think another useful addition to the API would be iterator(property).
This addition depends on the fact that we are able to work directly
with collection or not...

- why the signature of the method DynaBean#get(String name, String key)
is not rather get(String name, Object key) ?

Anyway, thanks for your replies,
Guillaume.

-----Message d'origine-----
De : Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk]
Envoyé : vendredi 13 février 2004 02:21
À : Jakarta Commons Developers List
Objet : Re: [beanutils] Indexed/Mapped DynaProperty


Shouldn't it be though - if you look at DynaProperty it has an isIndexed()
method which checks if the type is either an array or a List and it has an
isMapped() method which checks if the type is a Map. Doesn't that imply that
these define the types for mapped and indexed properties? Obviously an
implementation could ignore that and set/get values to other types
(WrapDynaBean being an example that could break that rule). Interesting
enough BasicDynaBean doesn't bother using these methods, but duplicates the
code and I guess if the standard implementation ignores them, it doesn't
give them much weight.

Also, maybe my solution would suit Guillaume - because perhaps he knows all
his mapped/indexed properties are backed by Maps, Lists and arrays and he
can live with that - mine are and I don't think thats much of a restriction
as they are only types and not implementations.

Don't get me wrong, I'm not arguing against an API change - I think
size(property) and keySet(property) methods would be v. useful additions to
the API - less getting and casting - making code neater and simpler.

Niall


----- Original Message ----- 
From: "robert burrell donkin" <robertburrelldonkin@blueyonder.co.uk>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Thursday, February 12, 2004 10:43 PM
Subject: Re: [beanutils] Indexed/Mapped DynaProperty


> i think that the issue is that though the property acts like a map,
> there is actually no guarantee that it will actually be backed by a
> map. a DynaBean is quite at liberty to use something different - for
> example, instances of an enumeration class.
>
> that's why i think an addition to the API would be needed which would
> allow the underlying implementation to be supply the information
> required.
>
> - robert
>
> On 10 Feb 2004, at 23:22, Niall Pemberton wrote:
>
> > I don't understand what the issue is, if you want the keyset fro
> > example
> > then...
> >
> >     Map myMap = (Map)myDynaBean.get("myMapPropertyName");
> >     Set myKeySet = myMap.keySet()
> >
> > Niall
> >
> >
> > ----- Original Message -----
> > From: "robert burrell donkin" <robertburrelldonkin@blueyonder.co.uk>
> > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > Cc: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
> > Sent: Tuesday, February 10, 2004 10:26 PM
> > Subject: Re: [beanutils] Indexed/Mapped DynaProperty
> >
> >
> >> hmmm....
> >>
> >> bit of a tough one this. i think that it'd involve an addition to the
> >> DynaBean's API. this is question probably belongs on the dev list so
> >> i'd suggest that we take it there. (if you're unwilling to process -
> >> by
> >> filtering - the torrent of mail that is commons-dev then you might
> >> like
> >> to subscribe through the news bridge at gname, i think.)
> >>
> >> - robert
> >>
> >> On 6 Feb 2004, at 09:07, guillaume.tuloup@fr.thalesgroup.com wrote:
> >>
> >>>
> >>>  Hi,
> >>>
> >>>   is it possible to have the length/keyset of an indexed/mapped
> >>> dynaproperty
> >>> ? My wish is to copy a dynaproperty from a dynabean to another, any
> >>> other
> >>> solution will be appreciated...
> >>>
> >>> TIA,
> >>> Guillaume.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message