On 16/05/2009, at 12:07 PM, Mike Schrag wrote:
I'm not sure this is really any better ... Fundamentally there's a ?
in that param, and as a result, it's impossible to do a put in a
typesafe way. You don't know what V is. I _think_ the signature as
it is now is actually correct, but if you need to insert into that
map inside createRequest, you simply have to copy it. I don't think
it's possible to ensure compiler-enforceable type-safety in any
other way (which is to say, "accurate type safety").
Mike is right, you cannot safely insert anything into a wildcard
parameterised "producer" type (? extends T) because you do not know
what subtype of T it is actually meant to contain. You only know that
it will "produce" elements that are assignable to T. If you want to
"put" anything, or rather have it "consume" values, it needs to be
parameterised with the form <? super T>, which will accept values that
are assignable to T. Hence the PECS mantra, Producer extend Consumer
super. There is no way to express both a producer and consumer using
a single wildcard expression.
Consumer:
Map<String, ? super List<String>> allows for:
m.put("foo", new ArrayList<String>("bar"));
m.put("foo", new NSArray<String>("bar"));
You can safely insert anything that is a List<String>
and
m = new NSDictionary<String, List<String>>();
but not
m = new NSDictionary<String, NSArray<String>>();
You cannot safely upcast from a more specific type to List<String>
Producer:
Map<String, ? extends List<String>> allows for:
List<String> t = m.get("foo");
but not
NSArray<String> t = m.get("foo");
Everything you retrieve will be assignable to List<String>
and
m = new NSDictionary<String, NSArray<String>>();
m = new HashMap<String, ArrayList<String>>();
m = new NSDictionary<String, List<String>>();
You can safely upcast to the more generic type of Map<String,
List<String>>
Getting back to the original example:
public WORequest createRequest(String method,String url,String
anHTTPVersion,Map<String,? extends List<String>> someHeaders,NSData
content,Map<String,Object> someInfo)
It's unfortunately that the method signature of someHeaders was
changed from NSDictionary to Map because the original contract of
NSDictionary implies immutability, while Map has no such implication.
But the intent can still be derived from the type parameters as being
a producer. If you are overriding this method you should not assume
that the someHeaders Map your were passed is mutable, you should clone
it to a concrete mutable type if you wish to modify it.
On May 15, 2009, at 9:51 PM, Henrique Prange wrote:
Hi Mike,
The following solution doesn't solve the unchecked type cast
problem. But it respect PECS definition and accept a Map<String,
NSArray<String>> as parameter. Do you think it is reasonable?
public <V extends List<String> > WORequest treateRequest(String
method, String url, String anHTTPVersion, Map<String, ? super V>
someHeaders, NSData content, Map<String, Object> someInfo) {
...
someHeaders.put("foo", (V) Collections.singletonList("bar"));
...
}
Cheers,
Henrique
On May 15, 2009, at 8:29 PM, Mike Schrag wrote:
Map< String, List< String >> correctHeaders = new HashMap<
String, List< String > >();
btw, this is what i was saying that the only typesafe way to do
this is to copy the original headers -- so you would do new
HashMap<String, List<String>>(originalHeaders) and then you'd have
a properly typesafe <String, List<String>> that you can happily
insert into whatever List<String> subtypes you want inside of
createRequest. But it takes a copy to do it, which kind of sucks.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/hprange%40gmail.com
This email sent to hpra...@gmail.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
This email sent to msch...@mdimension.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/qdolan%40gmail.com
This email sent to qdo...@gmail.com
--
Seeya...Q
Quinton Dolan - qdo...@gmail.com
Gold Coast, QLD, Australia (GMT+10)
Ph: +61 419 729 806
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
