Fun with method references

[Neal Gafter]

I'm saying that your proposal is unsound in the sense that a program in your extension that compiles with no diagnostics can result in heap pollution (variables whose dynamic and static types do not agree).  BGGA does not have that problem.  You can't "solve" the problem of reification using erasure.

-Neal

On Aug 6, 2010, at 10:50 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:

> The area that I didn't solve was arrays of function types, I could only do these by erasing the type (i.e. non-reified). Since all the proposals have this problem of erased function types in arrays, including BGGA, I think the characterisation 'unsound' is a tad strong. Or are you saying that all function type proposals, including BGGA, are unsound?
> 
> On 7 August 2010 13:11, Neal Gafter <neal at gafter.com> wrote:
> Why are you sending pointers to a proposal that has been shown to be unsound?
> 
> -Neal
> 
> On Aug 6, 2010, at 9:13 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 
> > @Rémi,
> >
> >> Not a good example, in my opinion.
> >> using SAM interfaces instead:
> >>
> >> interface Foo1 {...}
> >> interface Foo2 {...}
> >>
> >> void foo(Foo1 foo) { ... }
> >> void foo(Foo2 foo) { ... }
> >
> > But this is easily resolved with a cast
> >
> >> interface Handler<A> {
> >>   public int handle(A a);
> >> }
> >>
> >> void foo(Handler<String> stringHandler) { ... }
> >> void foo(Handler<Bar> barHandler) { ... }
> >
> > This is the exactly the same problem that happens with erased function types
> > and I assume that we don't want is more of these problems. The only way out
> > of this problem for function types (and generics) is to reify them:
> >
> > http://www.artima.com/weblogs/viewpost.jsp?thread=278567
> >
> >  -- Howard.
> >
> 
> 
> 
> -- 
>   -- Howard.
>