Closures prototype equivalence between closures and methodrefs

[Mark Mahieu]

On 13 Aug 2008, at 16:04, Neal Gafter wrote:

> Subtype relationships among reference types must require no  
> conversion code. For example, converting a List<? extends Number>  
> to a List<? extends Object> requires no code.

Well, quite :)  I believe I described some possible outcomes that  
might equally apply to violation of that principle, but I wasn't  
asking for a change to the meaning of subtyping in Java ;)

> If we support more general conversions among function types I  
> believe it ought to be implemented by putting the underlying  
> interfaces in some kind of normal form - for example, using Void  
> for the result type in the interface when the user wrote void in  
> the function type.  All that is possible, but I'm reluctant to take  
> on major changes to the spec at this stage.

Not asking you to, in fact your last point is something I  
fundamentally agree with.  I believe you've taken the BGGA prototype  
(and more importantly the spec, plus changes) to a point where it can  
and should be developed further by some form of expert group.  There  
is probably now more information from the community at large  
regarding closures than there has been for any other Java language  
change prior to its introduction.

Regards,

Mark


> On Wed, Aug 13, 2008 at 3:29 AM, Mark Mahieu  
> <mark at twistedbanana.demon.co.uk> wrote:
> I must admit that I've come close to reporting similar non-bugs,  
> because even though I *know* - having read the spec far too many  
> times - that the conversion is only applicable to closures, I've  
> found it's very easy to slip into thinking that assignment  
> compatibility works the same way for function types.  At least for  
> the subtler aspects like boxing or void vs Void.
>
> So I'll ask the question: why is the conversion applicable to  
> closures only, and not to function types as well?
>
> Presumably if it were allowed for function types then it would be  
> trivial to write a program which appears to have stable performance  
> and memory usage but which actually degrades in performance and  
> eventually blows up with an OutOfMemoryError or StackOverflowError,  
> but I'm curious to know what the real reasons are.
>
> Regards,
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20080813/8c46bd44/attachment.html