Notes on implementing concise calls to constructors with type 	parameters
    Howard Lovatt 
    howard.lovatt at iee.org
       
    Wed May 20 01:43:43 PDT 2009
    
    
  
Hi Neal,
Sorry for the slow response - end of FY in Australia :(
2009/5/19 Neal Gafter <neal at gafter.com>:
> I don't understand how this is all supposed to work when typeRHS is absent
> and is then inferred to be a generic type involving wildcards (e.g. List<?
> extends Number>).  Are we supposed to just drop the wildcards?
Use the bound or the raw type in the case of multiple bounds, e.g.:
    // Translation
    // Original
    Ex<? extends String> eues = new Ex<String>(); // Ex<? extends
String> eues = new();
    Ex<? super String>     eles = new Ex<String>();  // Ex<? super
String>    eles = new();
> It seems madness to ignore the types of the (constructor) parameters, the
> type parameter bounds, the relationship between the type parameters in
> typeLHS and typeRHS, etc, in doing type inference.  That's probably not
> something that can be done "later" because of compatibility.
The argument goes that in Java you specify the type on the left, so that:
int i = "s";
Is an error, whereas in Scala a mistake like:
def i = "s" // meant to be an int
Isn't caught.
Therefore the following should be an error:
Cell<Integer> c = new( "s" );
Which implies left to right inference. If you are trying to do right
to left inference, like Scala, then using the arguments to infere type
is a good choice. However, the algorithm proposed doesn't do that, so
that it catches errors like traditional Java does.
> For an example, consider
>
> class Permutation<T> implements Map<T,T> { ... }
>
> Textual substitution cannot work with this class.
I don't get the example, I must be missing something - can you elaborate please?
[spin] to next email
> One more thing.  What if "genericParametersRHS" contain captured wildcards or conjunctive types?
Did you mean LHS, can you give an example?
Have you in mind something like this?
class ExC<T extends Object & Comparable<? super T>> {}
class ExT implements Comparable<ExT> { ...  }
    // Translation                                          // Original
    ExC<ExT>   ct__ = new ExC<ExT>();   // ExC<ExT>   ct__ = new();
Or are you think of something like:
static <T extends Object & Comparable<? super T>> void method( Ex<T> e ) {}
   method( new() );
Which would translate to:
  method( new Ex() );
Because new Ex<Object & Comparable<capture of ? super T>> isn't
ilegal. IE for multiple bounds use raw types.
 -- Howard.
    
    
More information about the coin-dev
mailing list