• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Curly Generics Question - Update
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Curly Generics Question - Update


  • Subject: Re: Curly Generics Question - Update
  • From: Lachlan Deck <email@hidden>
  • Date: Sat, 16 May 2009 09:12:32 +1000

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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Curly Generics Question - Update
      • From: Mike Schrag <email@hidden>
    • Re: Curly Generics Question - Update
      • From: Mike Schrag <email@hidden>
References: 
 >Curly Generics Question (From: Andrew Lindesay <email@hidden>)
 >Re: Curly Generics Question - Update (From: Andrew Lindesay <email@hidden>)
 >Re: Curly Generics Question - Update (From: Jim Kinsey <email@hidden>)
 >Re: Curly Generics Question - Update (From: Mike Schrag <email@hidden>)

  • Prev by Date: Re: [OT] JD-Eclipse plug-in available for Mac OS X
  • Next by Date: Re: Curly Generics Question - Update
  • Previous by thread: Re: Curly Generics Question - Update
  • Next by thread: Re: Curly Generics Question - Update
  • Index(es):
    • Date
    • Thread