Java lambdas(JSR 335):为什么“消除对未绑定内部类构造函数引用的支持"? [英] Java lambdas (JSR 335): Why "eliminate support for unbound inner class constructor references"?

问题描述

在当前的JSR 335草案中，有提到更改日志 0.6.0的条目它消除了对未绑定内部类构造函数引用的支持".

In the current JSR 335 draft, it's mentioned in the change log entry for 0.6.0 that it "eliminated support for unbound inner class constructor references".

为说明起见，假设您有一个名为A的外部类和一​​个名为B的内部类，并且想要一个采用A并创建新的B实例的函数:

To illustrate, suppose you have an outer class named A and an inner class named B, and you want a function that takes an A and creates a new B instance:

Function<A, A.B> foo = a -> a.new B();

在0.6.0之前，您还可以使用构造函数引用语法执行相同的操作(甚至记录在

Prior to 0.6.0, you can also use the constructor reference syntax to do the same thing (it's even documented in State of the Lambda):

Function<A, A.B> foo = A.B::new;

如上所述，该语法在0.6.0中不再受支持.我真的很想知道为什么.

As mentioned above, that syntax is no longer supported in 0.6.0. I'm really curious to know why.

我浏览了 lambda-spec-experts 和 lambda-dev 邮件列表，找不到任何有关它的信息.

I've looked through the archives for the lambda-spec-experts and lambda-dev mailing lists, and cannot find any information about it.

推荐答案

很明显，"new"是关键字，而不是方法，并且"new"作为方法的所有使用在编译器中都是特殊情况.我可以容易地想象到他们想要清理编译器，以减少使用琐碎问题的可能性最小的用法.

It's evident that the 'new' is a keyword, not a method, and that all involvment of 'new' as a method are special cases in the compiler. I can easily imagine they wanted to clean up the compiler of least likely usages which have trivial workarounds.

猜测:与我们尚不知道的即将到来的JLS可能还有一些冲突/歧义可以解决，这是一个过渡更改，旨在最大程度地减少回归.提出问题后的5-6年，您是否会遭受这种变化的折磨?哈哈

Speculation: there maybe also some collisions/ambiguities to resolve with upcoming JLS we don't know about yet, and this is a transition change to minimize regressions. 5-6 years after your question, do you suffer at all from this change? LOL

这篇关于Java lambdas(JSR 335):为什么“消除对未绑定内部类构造函数引用的支持"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！