Java 7钻石运营商：为什么难以实施？ [英] Java 7 diamond operator: why was it difficult to implement?

问题描述

我观看了Oracle OTN虚拟事件：Java SE和JavaFX 2。0（2012年2月28日），并在讨论新的钻石运算符时（ Map< String，List< String>> myMap = new HashMap<>（）; thing）发言者提到它并不像人们想象的那么简单，因为它不是一个简单的令牌替换。

I watched the Oracle OTN Virtual Event: Java SE and JavaFX 2.0 (28 Feb 2012) and while talking about the new diamond operator (that Map<String, List<String>> myMap = new HashMap<>(); thing) the speaker mentioned that it was not as simpleto implement than one might think, as it is not a simple token replacement.

我的问题是为什么？为什么不能将这个实现简单地从变量的声明中取出并将其放入菱形运算符？

My question is why? Why can't be this implemented as simply taking the string from the variable's declaration and put it into the diamond operator?

推荐答案

我也没有实现它，所以我只能猜测。

I didn't implement it either, so I can only guess.

但是通常这些东西比看起来更复杂的原因是第一次检查仅查看最常见（或最公开）的用例。在这种情况下，它是你提到的那个。从理论上讲，它应该很容易准确指定，并且应该很容易在编译器中实现。

But usually the reason these things are more complex than they seem is that first inspection only looks at the most common (or most publicized) use case. In this case it's the one you mentioned. In theory that should be easy to specify exactly and it should be rather easy to implement in a compiler.

然而，钻石运算符（技术上不是运算符，方式）也可以以不同的方式使用：

However, the diamond operator (which is not technically a operator, by the way) can be used in different ways as well:

someMethodWithGenericArguments(new HashMap<>());
new SomeGenericClass(new HashMap<>());
T foo = new SomethingRelatedToT<>(); // where T is a generic type parameter

在这些情况下，简单的令牌替换显然不再有效，你需要涉及真实类型分析的实际类型推断（即它是一个完全不同的抽象层次，因为它是一个简单的令牌替换）。

In those cases a simple token replacement obviously no longer works, you need actual type inference involving real type analysis (i.e. it's on an entirely different abstraction level as a simple token replacement would be).

这篇关于Java 7钻石运营商：为什么难以实施？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！