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:
MapString, ? super ListString allows for:
m.put(foo, new ArrayListString(bar));
m.put(foo, new NSArrayString(bar));
You can safely insert anything that is a ListString
and
m = new NSDictionaryString, ListString();
but not
m = new NSDictionaryString, NSArrayString();
You cannot safely upcast from a more specific type to ListString
Producer:
MapString, ? extends ListString allows for:
ListString t = m.get(foo);
but not
NSArrayString t = m.get(foo);
Everything you retrieve will be assignable to ListString
and
m = new NSDictionaryString, NSArrayString();
m = new HashMapString, ArrayListString();
m = new NSDictionaryString, ListString();
You can safely upcast to the more generic type of MapString,
ListString
Getting back to the original example:
public WORequest createRequest(String method,String url,String
anHTTPVersion,MapString,? extends ListString someHeaders,NSData
content,MapString,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 MapString,
NSArrayString as parameter. Do you think it is reasonable?
public V extends ListString WORequest treateRequest(String
method, String url, String anHTTPVersion, MapString, ? super V
someHeaders, NSData content, MapString, 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
HashMapString, ListString(originalHeaders) and then you'd have
a properly typesafe String, ListString that you can happily
insert into whatever ListString 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:
