Hashes again

I've been playing around with the BeansWrapper, but it doesn't really  
behave as expected (at least as I thought it would).

The first issue I ran into was that I couldn't figure out the syntax  
to get something out of a Map<Integer, String>. I tried these  
variations with no luck:

	- bean.map(1)
	- bean.map.get(1)
	- bean.map[1]

The second thing I noticed is that Map's aren't really Map's any  
longer. They are now Object's. This means that their keys sequence  
contains their methods, which is really not what I want.

I guess what I'm wondering is if there is a way to have these things:

	- Have FM work with Collections only as collections, without any  
monkeying around with Map keys or creating new collections that adapt  
the original collections
	- Have FM treat other non-primitives as JavaBeans as well as  
reflectable classes

It seems to me that FM should be capable of handling all of these  
cases with Maps that would solve the first requirement:

	1. bean.map[0]
	2. bean.map.key
	3. bean.map['foo']
	4. bean.map[otherObject]

#1 would assume Map<Integer, Object>, #2 would assume Map<String,  
Object>, #3 would assume Map<String, Object>, and #4 would assume  
Map<Object, Object>. This would cover all cases and not interfere with  
other collections because these cases would only apply if 'bean.map'  
implemented Map. In fact, if your wrapped object instance has generics  
that can be inspected from the Java code, this becomes even better and  
#1 could figure out the Number sub-class to use. All the other cases  
could use toString on the key if the Map is in fact Map<String, Object>.

-bp


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects