I did not thought about ´asking´ HiveMind to transform something based
on type handlers. I was thinking about the same or a similar usage as
for services. In the defintion of a configuration point it could be
possible to define the ´transformation´, so that this configuration
will always be transformed e.g. to a Map. So for that configuration you
could 'ask' for a map.
But I have to admit, that I mostly use maps and lists.
James Carman wrote:
Typically, to create a Map from a List, you use some calculated value based
on the actual object as the key and use the actual object as the value. How
hard is it to write code that does that for you in a reusable fashion so
that you can wrap the returned list? Using the Commons Collections API...
public static Map toMap( final Collection c, final Transformer
keyTransformer )
{
final Map map = new HashMap();
CollectionUtils.forAllDo( c, new Closure()
{
public void execute( Object object )
{
map.put( keyTransformer.transform( object ), object );
}
});
return map;
}
In the proposed API, what if someone hands you the class TreeMap? Do we
instantiate one using Class.newInstance() and then ask if that instance is a
Map or a Collection and handle it accordingly? Or do we set up a
registration system that we use to register configuration type handlers?
I'm just trying to get an idea of what is expected. I don't really like the
idea, but I won't vote against it or anything. I'll just scoff at the API
to myself every time I see it. :-)
-----Original Message-----
From: Knut Wannheden [mailto:[EMAIL PROTECTED]
Sent: Friday, July 08, 2005 10:58 AM
To: [email protected]
Subject: Re: Registry Vs Module: getMappedConfiguration
On 7/8/05, James Carman <[EMAIL PROTECTED]> wrote:
How about this?
new HashSet( registry.getConfiguration( "MyConfiguration" ) );
This just allows you to get a Set view of a configuration, but you
can't get a Map or other "structured" view like this.
I don't think it's worth cluttering up the API with reflection-based
methods
if we don't have to IMHO.
I understand Stefan's argument and I think we should consider adopting
something like it. It isn't any more difficult to implement and it
solves the naming problem too :-) Although I must say I can for the
moment not think of any good other representations than List and Map.
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
