A simple solution for [] access that can trivially be added to List and Map.

[Reinier Zwitserloot]

Er, right. Scratch that idea. Well, that, or we allow some sort of  
post-processing in the class loader, so that any class that flies by  
is instrumented with the appropriate synthetic wrappers if they aren't  
there.

NB: Lawrence, asking users to import static stuff isn't exactly  
something to just dance around. That's quite a big concern. I'd  
personally rate [] support 'hardcoded' onto java.util.List and  
java.util.Map as a far better plan than forcing static imports just to  
make [] work.

  --Reinier Zwitserloot



On 2009/26/06, at 00:32, Neal Gafter wrote:

> On Thu, Jun 25, 2009 at 12:46 PM, Reinier
> Zwitserloot<reinier at zwitserloot.com> wrote:
>> Those additions are backwards and migration compatible, due to step  
>> 1,
>> which legally allows both map and list's existing set/put methods to
>> return something, even though in the SetIndex/SetWithKey interfaces,
>> set/put return void. All existing class files that implement List  
>> and/
>> or Map will seamlessly support the indexing operations, and any
>> existing source code that implements Map or List or a child  
>> interface/
>> class thereof continue to compile to the same semantic meaning  
>> without
>> introducing any (new) errors and warnings.
>
> Unfortunately, this strategy isn't binary compatible.  In order to
> allow this new form of "covariant" returns, the compiler will need to
> produce bridge methods in the implementation of every Map and List
> class.  Existing class files simply don't contain those bridge methods
> today.
>
> -Neal