Re: Curly Generics Question - Update
you should clone it to a concrete mutable type if you wish to modify it. have fun with this btw ... the cherry on top is that you can't even reliably CLONE these stupid things, because 1) cloning in java is retarded and 2) even if you can clone, you might just be cloning an immutable map (if they passed in NSDict, cloning doesn't get you far). I think you literally have to just copy it into a new NSMutableDict or a HashMap, which, of course, throws away Anjo's dream of passing in a TreeMap. 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Curly Generics Question - Update
Hi Mike and Jim; Thanks for the explanation Mike; that makes logical sense now and I had reverted to the cast in the end myself. Jim; good idea with the extra method as the concrete argument of java.util.List -- that might be good too. cheers. well, no matter what you do, i think you're going to throw out type safety, so inside the method, you could just cast the headers to > : ___ Andrew Lindesay www.lindesay.co.nz ___ 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
Re: Curly Generics Question - Update
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 , 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> allows for: m.put("foo", new ArrayList("bar")); m.put("foo", new NSArray("bar")); You can safely insert anything that is a List and m = new NSDictionary>(); but not m = new NSDictionary>(); You cannot safely upcast from a more specific type to List Producer: Map> allows for: List t = m.get("foo"); but not NSArray t = m.get("foo"); Everything you retrieve will be assignable to List and m = new NSDictionary>(); m = new HashMap>(); m = new NSDictionary>(); You can safely upcast to the more generic type of MapList> Getting back to the original example: public WORequest createRequest(String method,String url,String anHTTPVersion,Map> someHeaders,NSData content,Map 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 MapNSArray> as parameter. Do you think it is reasonable? public > WORequest treateRequest(String method, String url, String anHTTPVersion, Map someHeaders, NSData content, Map 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>(originalHeaders) and then you'd have a properly typesafe > that you can happily insert into whatever List 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
Re: Curly Generics Question - Update
Am 16.05.2009 um 01:29 schrieb Mike Schrag: 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>(originalHeaders) and then you'd have a properly typesafe > that you can happily insert into whatever List subtypes you want inside of createRequest. But it takes a copy to do it, which kind of sucks. As the whole point of this stupid and annoying API change to Map was that you could maintain order of the parameters, I'd at least use a TreeMap :) Cheers, Anjo ___ 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
Re: Curly Generics Question - Update
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"). ms 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 MapNSArray> as parameter. Do you think it is reasonable? public > WORequest treateRequest(String method, String url, String anHTTPVersion, Map someHeaders, NSData content, Map 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>(originalHeaders) and then you'd have a properly typesafe > that you can happily insert into whatever List 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Curly Generics Question - Update
Hi Mike, The following solution doesn't solve the unchecked type cast problem. But it respect PECS definition and accept a MapNSArray> as parameter. Do you think it is reasonable? public > WORequest treateRequest(String method, String url, String anHTTPVersion, Map someHeaders, NSData content, Map 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>(originalHeaders) and then you'd have a properly typesafe > that you can happily insert into whatever List 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Curly Generics Question - Update
On 16/05/2009, at 10:03 AM, Chuck Hill wrote: On May 15, 2009, at 4:59 PM, Lachlan Deck wrote: Generics are great mostly - but there are times when it's just downright annoying :-). Sounds like Maven! :-P Touché ;-) But still lovin' your work as the unlikely ambassador, finding every opportunity .. Maven here, maven there, maven loving everywhere ;-) with regards, -- Lachlan Deck ___ 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
Re: Curly Generics Question - Update
On May 15, 2009, at 4:59 PM, Lachlan Deck wrote: Generics are great mostly - but there are times when it's just downright annoying :-). Sounds like Maven! :-P -- Chuck Hill Senior Consultant / VP Development Come to WOWODC'09 in San Fran this June! http://www.wocommunity.org/wowodc09/ ___ 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
Re: Curly Generics Question - Update
On 16/05/2009, at 9:27 AM, Mike Schrag wrote: 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 nslist = null; someHeaders.put( "foo", nslist ); // compile error correctHeaders.put( "foo", nslist ); // no problems NSMutableArray array = null; someHeaders.put( "foo", array ); // compile error correctHeaders.put( "foo", array ); // no problems } You don't need extends for interfaces AFAIK. Not sure what you're showing here, but you are correct that you don't need extends to control the value you put into the map. You need the extends to control what generic impls you can pass in as the PARAMETER to the method. Ugh - yeah. Helps if I save the editor :-) So if you're showing that a Map> allows you to put a subtype of List as the value, I totally agree. The problem is that a Map> is NOT assignable to a Map> -- this is the Integer vs Number problem*, and it's not a typesafe operation. Right - lights are back on now. Cool. * I keep this in my Stickies in like 24pt type, so every time I say "WTF CAN'T I DO THAT", i can run stickies and remind myself: WHY IT'S ILLEGAL TO UPCAST GENERICS Map integers = new HashMap(); Map numbers = integers; // illegal numbers.put("str", Long.valueOf(1)); // and this is why now a long is in integers Generics are great mostly - but there are times when it's just downright annoying :-). with regards, -- Lachlan Deck ___ 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
Re: Curly Generics Question - Update
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 HashMapList>(originalHeaders) and then you'd have a properly typesafe > that you can happily insert into whatever List 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Curly Generics Question - Update
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 nslist = null; someHeaders.put( "foo", nslist ); // compile error correctHeaders.put( "foo", nslist ); // no problems NSMutableArray array = null; someHeaders.put( "foo", array ); // compile error correctHeaders.put( "foo", array ); // no problems } You don't need extends for interfaces AFAIK. Not sure what you're showing here, but you are correct that you don't need extends to control the value you put into the map. You need the extends to control what generic impls you can pass in as the PARAMETER to the method. So if you're showing that a Map> allows you to put a subtype of List as the value, I totally agree. The problem is that a Map> is NOT assignable to a Map> -- this is the Integer vs Number problem*, and it's not a typesafe operation. In your example, map a Map> and try to pass that into createRequest -- it will work, but you can't insert into it, because you have no idea precisely what subtype of List the generic was actually written for -- the "? extends" screws your ability to insert into it in a typesafe way. If you remove the "? extends" you can put any list subtype into the value, but you can't pass in a generic that is declared as anything except PRECISELY >, which causes the problem below: 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. public static void doSomething() { Map> testMap = new HashMapLinkedList>(); doSomethingElse(testMap); } public static void doSomethingElse(Map> test) { } this is a compile error .. if the method signature removes the ? extends List you can't pass in a generic that has a V that is explicitly declared as a subtype of List, you can only pass in a V that is declared as List. ms * I keep this in my Stickies in like 24pt type, so every time I say "WTF CAN'T I DO THAT", i can run stickies and remind myself: WHY IT'S ILLEGAL TO UPCAST GENERICS Map integers = new HashMap(); Map numbers = integers; // illegal numbers.put("str", Long.valueOf(1)); // and this is why now a long is in integers ___ 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
Re: Curly Generics Question - Update
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" so you can pass in NSArray, which is a pretty common implementation. You also can't necessarily just assume people can declare their vars as List instead of NSArray because you don't know where that var came from (the general case is that you really do want it to be enforced as >). 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" this does NOT mean you can just put anything that extends List into the value, rather, it means you can pass in any generic that has a List that is a subclass of List. The distinction is that if you pass in NSArray as the list, you can't just put any list into it -- it explicitly has to be an NSArray, 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 List> then you have to do a copy operation to convert > to > ... 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 extends List { 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 nslist = null; someHeaders.put( "foo", nslist ); // compile error correctHeaders.put( "foo", nslist ); // no problems NSMutableArray 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 (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
Re: Curly Generics Question - Update
well, no matter what you do, i think you're going to throw out type safety, so inside the method, you could just cast the headers to > : Map> badCast = (MapList>)headers; badCast.put("a", new LinkedList()); ms On May 15, 2009, at 8:56 AM, Jim Kinsey wrote: Hi Andrew, what the calling method ought to be doing though is declaring the list it passes as Map> and hiding the concrete List implementation, negating the need for the wildcard. I tried it with a concrete implementation of List as well, but this also raised an error in a similar fashion. It's got me. You are right, I could create a new Map and use that instead as it should work, but that would be rather inelegant. I was meaning that as more of an example of why, possibly, the "bug" (I'm not sure it really can be called that yet) exists - that there was some calling code somewhere in the WO source which was passing in something declared a bit too concrete, so it got "fixed" by wildcarding the List parameter on createRequest rather than changing the declaration in the calling code to work to an interface. I think the only real solution which still involves overriding createRequest is to override without generics and suppress the warning; if you want to do lots of work within the overridden createRequest and like to have the generic type checking then you could pass this work on to a different method with appropriately generic arguments: @SuppressWarnings("unchecked") @Override public WORequest createRequest(String method, String aurl, String anHTTPVersion, Map someHeaders, NSData content, Map someInfo) { return genericCreateRequest(method, aurl, anHTTPVersion, someHeaders, content, someInfo); } private WORequest genericCreateRequest(String method, String aurl, String anHTTPVersion, Map> someHeaders, NSData content, Map someInfo) { someHeaders.put("foo", Collections.singletonList("bar")); return super.createRequest(method, aurl, anHTTPVersion, someHeaders, content, someInfo); } Cheers, Jim Could this be considered a bug in WOApplication? Yes, I think it is not quite right. cheers. ___ Andrew Lindesay www.lindesay.co.nz 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 (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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Curly Generics Question - Update
Hi Andrew, what the calling method ought to be doing though is declaring the list it passes as Map> and hiding the concrete List implementation, negating the need for the wildcard. I tried it with a concrete implementation of List as well, but this also raised an error in a similar fashion. It's got me. You are right, I could create a new Map and use that instead as it should work, but that would be rather inelegant. I was meaning that as more of an example of why, possibly, the "bug" (I'm not sure it really can be called that yet) exists - that there was some calling code somewhere in the WO source which was passing in something declared a bit too concrete, so it got "fixed" by wildcarding the List parameter on createRequest rather than changing the declaration in the calling code to work to an interface. I think the only real solution which still involves overriding createRequest is to override without generics and suppress the warning; if you want to do lots of work within the overridden createRequest and like to have the generic type checking then you could pass this work on to a different method with appropriately generic arguments: @SuppressWarnings("unchecked") @Override public WORequest createRequest(String method, String aurl, String anHTTPVersion, Map someHeaders, NSData content, Map someInfo) { return genericCreateRequest(method, aurl, anHTTPVersion, someHeaders, content, someInfo); } private WORequest genericCreateRequest(String method, String aurl, String anHTTPVersion, Map> someHeaders, NSData content, Map someInfo) { someHeaders.put("foo", Collections.singletonList("bar")); return super.createRequest(method, aurl, anHTTPVersion, someHeaders, content, someInfo); } Cheers, Jim Could this be considered a bug in WOApplication? Yes, I think it is not quite right. cheers. ___ Andrew Lindesay www.lindesay.co.nz 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 (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
Re: Curly Generics Question - Update
Yeah this is a tricky one ... But you're right that the API is "? extends List" so you can pass in NSArray, which is a pretty common implementation. You also can't necessarily just assume people can declare their vars as List instead of NSArray because you don't know where that var came from (the general case is that you really do want it to be enforced as NSArray>). 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" this does NOT mean you can just put anything that extends List into the value, rather, it means you can pass in any generic that has a List that is a subclass of List. The distinction is that if you pass in NSArray as the list, you can't just put any list into it -- it explicitly has to be an NSArray, 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 List> then you have to do a copy operation to convert NSArray> to > ... Tough call on that one. If the method sig changes, it's annoying to people passing values in, but as it stands, i'm not sure it's possible to put values INTO it inside this method. ms On May 15, 2009, at 8:14 AM, Jim Kinsey wrote: Hi Andrew, I find it odd that the map should have ? extends List 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. 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.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> 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> and hiding the concrete List implementation, negating the need for the wildcard. e.g. works to impl rather than interface: NSMutableDictionary> someHeaders = new NSMutableDictionary>(); someHeaders.setObjectForKey(new NSMutableArray("bar"), "foo"); WORequest req = createRequest(method, aurl, anHTTPVersion, someHeaders, content, someInfo); vs. working just to interface: Map> someHeaders = new NSMutableDictionary>(); someHeaders.put("foo", new NSMutableArray("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) in the type Map> is not applicable for the arguments (String,List)" 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/jim.kinsey%40bbc.co.uk This email sent to jim.kin...@bbc.co.uk http://www.bbc.co.uk This e-mail (and any atta
Re: Curly Generics Question - Update
Hello Jim; Thanks for the reply. what the calling method ought to be doing though is declaring the list it passes as Map> and hiding the concrete List implementation, negating the need for the wildcard. I tried it with a concrete implementation of List as well, but this also raised an error in a similar fashion. It's got me. You are right, I could create a new Map and use that instead as it should work, but that would be rather inelegant. Could this be considered a bug in WOApplication? Yes, I think it is not quite right. cheers. ___ Andrew Lindesay www.lindesay.co.nz ___ 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
Re: Curly Generics Question - Update
Hi Andrew, I find it odd that the map should have ? extends List 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. 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.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> 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> and hiding the concrete List implementation, negating the need for the wildcard. e.g. works to impl rather than interface: NSMutableDictionary> someHeaders = new NSMutableDictionary>(); someHeaders.setObjectForKey(new NSMutableArray("bar"), "foo"); WORequest req = createRequest(method, aurl, anHTTPVersion, someHeaders, content, someInfo); vs. working just to interface: Map> someHeaders = new NSMutableDictionary>(); someHeaders.put("foo", new NSMutableArray("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) in the type Map> is not applicable for the arguments (String,List)" 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/jim.kinsey%40bbc.co.uk This email sent to jim.kin...@bbc.co.uk 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 (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
Re: Curly Generics Question - Update
Sorry wrong method; I obviously meant "put" rather than "add" in this example and "The method put(String,List) in the type Map> is not applicable for the arguments (String,List)" 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 (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
Curly Generics Question
I've been working with generics for quite a while (and quite like them) but this one has me stumped! public WORequest createRequest(String method,String url,String anHTTPVersion,Map> someHeaders,NSData content,Map someInfo) { ... someHeaders.add("foo", Collections.singletonList("bar")); ... } This causes a compile error "The method add(String,List) is undefined for the type MapList>". Any help appreciated! cheers. ___ Andrew Lindesay www.lindesay.co.nz ___ 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