On 15/05/2009, at 10:48 PM, Mike Schrag wrote:
Yeah this is a tricky one ... But you're right that the API is "?
extends List<String>" so you can pass in NSArray<String>, which is a
pretty common implementation. You also can't necessarily just
assume people can declare their vars as List<String> instead of
NSArray<String> because you don't know where that var came from (the
general case is that you really do want it to be enforced as
<String, NSArray<String>>). Basically, this method declaration
makes it easy and flexible for people passing in params, but it
makes it really complicated to add values to that map like Andrew is
finding. The deal is that the signature is "? extends List<String>"
this does NOT mean you can just put anything that extends
List<String> into the value, rather, it means you can pass in any
generic that has a List that is a subclass of List<String>. The
distinction is that if you pass in NSArray<String> as the list, you
can't just put any list into it -- it explicitly has to be an
NSArray<String>, but inside that method, you have no idea what the
ACTUAL type is. So Andrew's code is failing because the list type
he's putting in is whatever singletonList returns, but that's not
guaranteed to be match the passed-in type.
The problem is that if the method sig is changed to <String,
List<String>> then you have to do a copy operation to convert
<String, NSArray<String>> to <String, List<String>> ... Tough call
on that one.
No, no - you wouldn't have to do that at all. This is a bug.
// test interface
private static interface NSList<T> extends List<T>
{
public int count();
}
@Override
public WORequest createRequest( String method,
String aurl,
String anHttpVersion,
Map< String, ? extends List< String
>> someHeaders,
NSData content,
Map< String, Object > someInfo )
{
Map< String, List< String >> correctHeaders = new HashMap< String,
List< String > >();
NSList<String> nslist = null;
someHeaders.put( "foo", nslist ); // compile error
correctHeaders.put( "foo", nslist ); // no problems
NSMutableArray<String> array = null;
someHeaders.put( "foo", array ); // compile error
correctHeaders.put( "foo", array ); // no problems
}
You don't need extends for interfaces AFAIK.
If the method sig changes, it's annoying to people passing values in,
Map< String, NSArray< String >> someHeaders = null;
Map< String, Object > someInfo = null;
createRequest( "foo", "url", "1", someHeaders, null, someInfo );
No compile errors.
I'm not convinced that fixing the method signature would break
anything for anyone at all.
but as it stands, i'm not sure it's possible to put values INTO it
inside this method.
ms
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
