Notes on implementing concise calls to constructors with type parameters

[Peter Levart]

Hello Howard,

What Neal and others are trying to point out is that your "textual
substitution algorithm" is not defined. The name "textual" implies that it
should be simple. But the right thing to do is not simple at all. Have you
looked at the 3rd JLS section 15.12.2.7 ? To just scratch the surface, take
the following example:

public interface IntA<X, Y> { ... }

public class ClsA<Z> implements IntA<String, Z> { ... }

public class ClsB<Z> implements IntA<Z, Integer> { ... }

...
public void doIt(IntA<String, Integer> param) { ... }
...
// what should "textual substitution" do in the following 2 cases:
anInstance.doIt(new ClsA());
// vs.
anInstance.doIt(new ClsB());


Peter.


On Mon, May 18, 2009 at 10:13 AM, Howard Lovatt <howard.lovatt at iee.org>wrote:

> Hi Neal,
>
> Yes I should have spelled this out, it is one of those things obvious
> to the author but not to the reader. I would propose that given more
> than one method of the same name, method in example below, with the
> general declaration for each following the syntax:
>
> ... method ( typeLHS [<genericParametersLHS>] name , ... ) { ... }
>
> and given the call:
>
> ... method ( new [typeRHS] [<genericParametersRHS>] ( ... ) , ... );
>
> Then a three step procedure would be used:
>
> 1. If typeRHS is absent assume for step 2 type Void, where Void is the
> bottom type (in Java 7 this may be called Null but I chose Void to be
> consistent with the InvokeDynamic proposal)
>
> 2. Resolve method as normal and hence find typeLHS and if specified
> genericParametersLHS also
>
> 3. Apply textual substitution algorithm, i.e. If typeRHS is absent
> substitute typeLHS and if genericParametersRHS is absent and
> genericParametersLHS is present then substitute genericParametersLHS
>
> For example, given two methods:
>
> void method( Object notUsed ) { out.println( "Object" );  }
> void method( String notUsed ) { out.println( "String" );  }
>
> The call:
>
> method( new() );
>
> would print String because it would be translated by the textual
> substitution algorithm into method( new String() ), i.e. the same
> behaviour as method( null ) because null has type Void (bottom).
>
> Does that add sufficient clarity? I would be really interested if you
> can see a problem with the technique?
>
> If not the method maybe a good solution as it has many desirable
> characteristics (as listed in previous posts in this thread). I also
> note that many people would like a var or auto style declaration and
> maybe this proposal of text substitution can satisfy more people than
> other proposals, since it retains LHS types but saves re-specification
> of type, generic type, and doesn't require a diamond operator on the
> RHS.
>
>  -- Howard.
>
>
>