运算符重载与 JVM 处理之间的联系
Connection between operator overloading and JVM processing
我需要对此声明进行专家评审。我在最近的 java 面试中遇到了这种说法。
Adding Operator overloading to java would have definitely made design
more complex than without it, and it might have lead to more complex
compiler or slows the JVM .
证明这一点？
从上面的行我有 2 个问题，如果假设 java 中有运算符重载支持，它如何减慢 jvm，因为重载在编译时被解决， jvm 完全是关于 运行 时间观点（如果我错了，请纠正我）。
通过制作复杂的编译器，我们可以拥有更多的业务逻辑自由度。
几个想法：
(1) 重载并不总能在编译时解决。 Subclasses 可能会覆盖方法，并且在代码执行之前您不知道自己是父对象还是子对象 class。我们不知道运算符重载是如何实现的，但它可能具有相同的行为。
(2) 我不认为这通常是正确的。添加运算符重载（本质上是语法糖）并不能让你拥有更多的业务逻辑。可能表达得更简洁，但道理是一样的。考虑以下代码，其中 a、b 和 c 是相同 class 的实例（即它们不是标量）。逻辑是一样的，但有些人会喜欢不同的表达方式。
c = a.plus(b);
c = a + b;
我需要对此声明进行专家评审。我在最近的 java 面试中遇到了这种说法。
Adding Operator overloading to java would have definitely made design more complex than without it, and it might have lead to more complex compiler or slows the JVM .
证明这一点？
从上面的行我有 2 个问题，如果假设 java 中有运算符重载支持，它如何减慢 jvm，因为重载在编译时被解决， jvm 完全是关于 运行 时间观点（如果我错了，请纠正我）。
通过制作复杂的编译器，我们可以拥有更多的业务逻辑自由度。
几个想法：
(1) 重载并不总能在编译时解决。 Subclasses 可能会覆盖方法，并且在代码执行之前您不知道自己是父对象还是子对象 class。我们不知道运算符重载是如何实现的，但它可能具有相同的行为。
(2) 我不认为这通常是正确的。添加运算符重载（本质上是语法糖）并不能让你拥有更多的业务逻辑。可能表达得更简洁，但道理是一样的。考虑以下代码，其中 a、b 和 c 是相同 class 的实例（即它们不是标量）。逻辑是一样的，但有些人会喜欢不同的表达方式。
c = a.plus(b);
c = a + b;