为什么 Java 不支持结构?(只是出于好奇) [英] Why Java doesn't support structures ? (Just out of curiosity)

问题描述

我知道您可以使用公共字段或其他一些解决方法.或者，也许您根本不需要它们.但只是出于好奇为什么 Sun 不考虑结构.

I know you can use public fields, or some other workarounds. Or maybe you don't need them at all. But just out of curiosity why Sun leave structures out.

推荐答案

虽然 Java 可以支持任意多种类，但 Runtime 只支持几种变量类型:int、long、float、double 和 reference；此外，Runtime 仅识别几种对象类型:byte[]、char[]、short[]、int[]、long[]、float[]、double[]、reference[] 和非数组对象.系统会为每个引用变量或数组实例记录一个类类型，Runtime 会执行某些检查，例如确保存储到数组中的引用与数组类型兼容，但此类行为仅将对象类型视为数据".

Although Java can support arbitrarily many kinds of classes, the Runtime only supports a few variable types: int, long, float, double, and reference; additionally, the Runtime only recognizes a few object types: byte[], char[], short[], int[], long[], float[], double[], reference[], and non-array object. The system will record a class type for each reference variable or array instance, and the Runtime will perform certain checks like ensuring that a reference stored into an array is compatible with the array type, but such behaviors merely regard the types of objects as "data".

我不同意类的存在消除了对结构的需要的说法，因为结构具有与类对象根本不同的语义.另一方面，从运行时系统设计的角度来看，添加结构会使类型系统变得非常复杂.在没有结构体的情况下，类型系统只需要八种数组类型.向类型系统添加结构需要类型系统识别任意数量的不同变量类型和数组类型.这样的认识很有用，但 Sun 认为不值得这么复杂.

I disagree with the claim that the existence of classes eliminates the need for structures, since structures have semantics which are fundamentally different from class objects. On the other hand, from a Runtime-system design perspective, adding structures greatly complicates the type system. In the absence of structures, the type system only needs eight array types. Adding structures to the type system would require the type system to recognize an arbitrary number of distinct variable types and array types. Such recognition is useful, but Sun felt that it wasn't worth the complexity.

考虑到 Java 的运行时和类型系统运行的约束，我个人认为它应该包含有限形式的聚合类型.其中大部分将由语言编译器处理，但它需要运行时中的一些功能才能真正运行良好.给定一个声明

Given the constraints under which Java's Runtime and type system operate, I personally think it should have included a limited form of aggregate type. Much of this would be handled by the language compiler, but it would need a couple of features in the Runtime to really work well. Given a declaration

aggregate TimedNamedPoint
{ int x,y; long startTime; String name; }

像 TimedNamedPoint tpt; 这样的字段声明将创建四个变量:tpt.x, tpt.y 类型 int、long 类型的 tpt.startTime 和 String 类型的 tpt.name.声明该类型的参数的行为类似.

a field declaration like TimedNamedPoint tpt; would create four variables: tpt.x, tpt.y of type int, tpt.startTime of type long, and tpt.name of type String. Declaring a parameter of that type would behave similarly.

为了让这些类型有用，Runtime 需要做一些简单的添加:有必要允许函数在返回时在堆栈上留下多个值，而不是简单地只有五个返回值之一主要类型.此外，有必要在一个数组中存储多种类型的东西.虽然这可以通过创建声明为 TimedNamedPoint[12] 的东西来实现，但实际上是一个 Object[4]，它将被初始化以识别 的两个实例int[12]、long[12] 和 String[12]，最好有一种方法可以让代码构造一个单个数组实例可以保存 24 个 int 类型的值、12 个 long 类型的值和 12 个 String 类型的值.

For such types to be useful, the Runtime would need a couple of slight additions: it would be necessary to allow functions to leave multiple values on the stack when they return, rather than simply having a single return value of one the five main types. Additionally, it would be necessary to have a means of storing multiple kinds of things in an array. While that could be accomplished by having the creation of something declared as TimedNamedPoint[12] actually be an Object[4] which would be initialized to identify two instances of int[12], a long[12], and a String[12], it would be better to have a means by which code could construct a single array instance could hold 24 values of type int, 12 of type long, and 12 of type String.

就我个人而言，我认为对于 Point 之类的东西，简单聚合的语义会比类清晰得多.此外，缺乏聚合通常使得拥有一种可以同时返回多种信息的方法变得不切实际.在许多情况下，可以让一个方法同时计算和报告传入角度的正弦和余弦，而工作量比分别计算所需的工作少得多，但必须构造一个 SineAndCosineResult 对象实例将否定通过这样做可以获得的任何速度优势.执行模型不需要做太多改变，允许方法在返回时在计算堆栈上留下两个浮点值，但目前不支持这样的事情.

Personally, I think that for things like Point, the semantics of a simple aggregate would be much cleaner than for a class. Further, the lack of aggregates often makes it impractical to have a method that can return more than one kind of information simultaneously. There are many situations where it would be possible to have a method simultaneously compute and report the sine and cosine of a passed-in angle with much less work than would be required to compute both separately, but having to constructing a SineAndCosineResult object instance would negate any speed advantage that could have been gained by doing so. The execution model wouldn't need to change much to allow a method to leave two floating-point values on the evaluation stack when it returns, but at present no such thing is supported.

这篇关于为什么 Java 不支持结构?(只是出于好奇)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！