本地类型推断与实例 [英] Local Type Inference vs Instance

问题描述

我尝试扫描 JEP-286 有关本地类型推断的信息.我看到这仅适用于局部变量-可以理解.所以这确实有效:

I've tried to scan JEP-286 about local type inference. I see that this works only for local variables - understood. So this does work indeed:

public class TestClass {
    public static void main(String [] args){
        var list = new ArrayList<>();
        list.add("1");
        System.out.println(list.get(0)); // 1
    }  
}

我确实看到它无法编译:

I do see that this on the other hand does not compile:

public class TestClass {
    public var list = new ArrayList<>();
    public static void main(String [] args){

    }
}

很明显，事实并非如此，因为JEP是这样说的.现在我的问题:

It's obvious that it does not, since the JEP says so. Now my question:

对于声明为var的公共/受保护的成员，至少是IMO，完全有道理.但是，为什么即使它是private也不能编译?我只能假设您仍然可以通过反射保留该变量(而我无法获得这样的局部字段)...而获取该变量可能需要强制转换，好吧，很困惑. >

It makes perfect sense for a public/protected member declared as var to fail, at least IMO. But why does it not compile even if it's private? I can only assume that you can still get a hold of that variable via reflection (and I can't get local fields like this)... And getting that variable would require a cast, well, a very confused cast probably.

推荐答案

禁止字段和方法返回的类型推断的动机是API应该是稳定的.字段访问和方法调用在运行时由描述符链接在一起，因此，如果对实现的更改导致推断的类型发生更改(模删除)，则导致对推断的类型进行细微更改的事情可能导致现有的已编译客户端以可怕的方式中断.这对于实现而不是对API来说是明智的指导原则.

The motivation for forbidding type inference for fields and method returns is that APIs should be stable; field access and method invocation are linked by descriptor at runtime, so things that cause subtle changes to inferred types could cause existing compiled clients to break in terrible ways if a change to the implementation caused the inferred type to change (modulo erasure.) So using this for implementation, but not for API, is a sensible guiding principle.

问那么，私有字段和方法又如何呢?"是合理的.确实，我们很可能选择这样做.像所有设计决策一样，这是一个权衡.它可以使推理在更多的地方使用，以换取用户模型的更多复杂性. (我不太在乎规范或编译器的复杂性；这是我们的问题.)比添加诸如但是"字段之类的各种周转注意事项，更容易推理推断局部变量为是，字段和方法为否".如果方法是私有的，则方法也可以."在我们所做的事情上划清界限还意味着，将字段或方法从私有更改为非私有的兼容性后果不会与推理产生偶然的交互作用.

It is reasonable to ask "so, what about private fields and methods?" And indeed, we could well have chosen to do that. Like all design decisions, this is a tradeoff; it would enable inference to be used in more places, in exchange for more complexity in the user model. (I don't care as much about complexity in the spec or the compiler; that's our problem.) It is easier to reason about "inference for local variables yes, fields and methods no" than adding various epicyclic considerations like "but, fields and methods are OK if they are private". Drawing the line where we did also means that the compatibility consequences of changing a field or method from private to nonprivate doesn't have accidental interactions with inference.

因此，简单的答案是，以这种方式使语言更简单，而又不会使该功能的使用性大大降低.

So the short answer is, doing it this way makes the language simpler, without making the feature dramatically less useful.

这篇关于本地类型推断与实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！