Hi Andrew,
I find it odd that the map should have ? extends List<String> as a
parameter as the extension ought to be unnecessary (assuming callers
are working to the List interface) - any List implementation with a
String parameter fulfills List<String>. I like generics too, but have
come across similarly gnarly counter-intuitive things. I find that
often if you think about them enough they eventually make sense, but
this one has me stumped!
I see it came from overriding the WOApplication method - and if you
don't include the parameter in this way you get a compilation error.
This can be made to go away by overriding without providing the
generic parameters, which then produces a warning which you can
annotate away:
@SuppressWarnings("unchecked")
@Override
public WORequest createRequest(String method, String aurl,
String anHTTPVersion,
Map someHeaders, NSData content,
Map someInfo) {
someHeaders.put("foo",
Collections.<String>singletonList("bar"));
I suppose you might want to use this kind of wildcard extension if you
want to pass a Map which declares an extension of List elsewhere; e.g.
if there was a calling method which was passing a variable declared as
Map<String, NSMutableArray<String>> to this method there would be a
compilation error without the wildcard; arguably what the calling
method ought to be doing though is declaring the list it passes as
Map<String, List<String>> and hiding the concrete List implementation,
negating the need for the wildcard.
e.g. works to impl rather than interface:
NSMutableDictionary<String, NSMutableArray<String>> someHeaders =
new NSMutableDictionary<String, NSMutableArray<String>>();
someHeaders.setObjectForKey(new NSMutableArray<String>("bar"),
"foo");
WORequest req = createRequest(method, aurl, anHTTPVersion,
someHeaders, content, someInfo);
vs. working just to interface:
Map<String, List<String>> someHeaders = new
NSMutableDictionary<String, List<String>>();
someHeaders.put("foo", new NSMutableArray<String>("bar"));
WORequest req = createRequest(method, aurl, anHTTPVersion,
someHeaders, content, someInfo);
Both compile to current WOApplication API; former would not if the
wildcard were to be removed from createRequest.
Could this be considered a bug in WOApplication? I believe if this
method declaration had the wildcard extension removed and any calling
methods which need to be were fixed to work to interface rather than
implementation then this problem would go away and createRequest could
be overridden and worked with generically. Easy to say - I still find
myself preferring to work directly with NS implementations for key-
value-coding / EOQualifiers...
Cheers,
Jim
On 15 May 2009, at 03:54, Andrew Lindesay wrote:
Sorry wrong method; I obviously meant "put" rather than "add" in
this example and "The method put(String,List<String>) in the type
Map<String,capture#1-of? extends List<String>> is not applicable for
the arguments (String,List<String>)" is the problem.
I've been working with generics for quite a while (and quite like
them) but this one has me stumped!
___
Andrew Lindesay
www.lindesay.co.nz
_______________________________________________
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/jim.kinsey%40bbc.co.uk
This email sent to [email protected]
http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
_______________________________________________
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]
