有什么合理的理由,为什么原生属性不会成为 Java 7 的一部分?
5 回答
当然,还有一些与日程安排和资源有关的高级原因。属性的实现以及理解与其他语言特性的所有分支和交叉点是一项大型任务,类似于各种 Java 5 语言更改的规模。
但我认为 Sun 不推动属性的真正原因与闭包相同:
1)对于实现应该是什么样子没有达成共识。或者更确切地说,有许多相互竞争的替代方案,而对属性充满热情的人对实施的关键部分意见不一。
2)也许更重要的是,对于是否需要该功能缺乏共识。虽然很多人想要属性,但也有很多人认为它没有必要或有用(特别是,我认为服务器端的人认为属性对他们日常生活的重要性远没有摇摆程序员那么重要)。
这里的属性历史:
在 Java 中做“正确”的属性并不容易。Rémi Forax 的工作在弄清楚这可能是什么样子以及发现许多必须处理的“陷阱”方面尤其有价值。
同时,Java 7 已经花费了太长时间。闭包辩论是一个巨大的、有争议的分心,它浪费了很多本可以用来开发具有广泛支持共识的功能(如属性)的脑力。最终,决定限制对模块化的重大更改(Project Jigsaw)。该语言只考虑了“小改动”(在 Project Coin 下)。
JavaFX 拥有漂亮的属性支持,因此 Sun 清楚地了解属性的价值并知道如何实现它们。但是被 JavaFX 属性宠坏了,开发人员不太可能满足于 Java 中半生不熟的实现。如果它们值得做,那么它们就值得做对。
默认情况下,任何给定的事情都是“未完成”,因此不需要特别的理由来保持未完成的事情。相反,需要一些令人信服的理由才能将某件事从“未完成”转移到“计划”或“完成”。这种语言特征还没有足够令人信服的理由。
避免使用任何语言的属性还有两个原因:
属性不是非常面向对象的。使它们易于编写鼓励了对象仅提供其内部状态并且调用者对其进行操作的模式。该对象应提供更高级别的方法并保持其内部私有。下次您繁琐地实现 getter 时,请考虑调用者将如何处理数据以及您是否可以直接提供该功能。
属性鼓励可变状态(通过设置器),这使程序的可并行性降低。随着核心数量的增加,我们都应该努力使我们的对象不可变,以使并发推理更容易。下次您繁琐地实现 setter 时,请考虑将其删除并使对象不可变。
- 不够时间?
- 尚未正确指定?
- 由于java的实现难以添加到java?
- 认为不够重要,即其他事情被优先考虑?