为什么基元的包装器类没有二传手? [英] Why don't the wrapper classes for Primitives have a setter?
问题描述
Wrapper类(例如Integer，Double等)没有其内部原始值的setter的原因是什么?
我之所以这样问是因为这种功能将简化演算，并使Java语言更加灵活.
让我给你举一些例子.
1)让我们看下面的示例:
Integer x = new Integer(5);
x++;
幕后的先前代码正在执行自动装箱.像这样:
int x_tmp = x.intValue();
x_tmp++;
x = new Integer(x_tmp); // Yes that's a new memory allocation
由于此问题，在包装程序上进行演算比在普通原始类型上执行演算要慢.使用setter可以更轻松地增加内部值，而无需在堆上分配另一个对象.
2)困扰我的另一个问题是，在Java中不可能像在C(使用指针)或C ++(指针或引用)中编写交换函数一样.
如果我写void swap(Integer x, Integer y)，我将无法访问内部值，因为，交换值将是不可能的.
PS: 我的一个朋友建议我应该考虑更大的范围，并考虑并发性和类型不变性.
那么您对此有一个解释吗? 谢谢！
1)使用setter，包装器类型将是可变的.不变性在许多方面都是一件好事...线程，代码的一般易懂性等.例如，我个人认为Calendar和Date是可变的是可耻的.
实际上，您对x++;的扩展不太正确-它使用Integer.valueOf，而不是总是创建一个新值.例如:
Integer x = 5;
x++;
Integer y = 5;
y++;
// This prints true
System.out.println(x == y); // Compare references
只能像这样缓存有限范围的Integer值(规范定义了必须的行为方式，但是如果JRE希望这样做，则允许更大的范围). .，但这确实意味着它不会总是在创建一个新对象.
2)是的，Java没有通过引用传递.坦白说，我很少发现这是一个问题.您真的需要多久交换一次变量的值?
What is the reason why Wrapper classes (like Integer, Double, etc.) don't have a setter for their inner primitive value ?
I am asking this because that kind of functionality would have simplified calculus, and have made the Java language a little more flexible .
Let me give you some examples.
1) Let's take the following example:
Integer x = new Integer(5);
x++;
The previous code behind the scenes is performing autoboxing . Something like:
int x_tmp = x.intValue();
x_tmp++;
x = new Integer(x_tmp); // Yes that's a new memory allocation
Because of this problem doing calculus on Wrapper is slower than performing on plain primitive types. With a setter it would've been more easy to increment the inner value, without allocating another object on the heap.
2) Another issue that is bugging me is that is impossible in Java to write a swap function like I can do in C (using pointers) or in C++ (pointers or references).
If i write void swap(Integer x, Integer y) I cannot acces the inner value because, and It is going to be impossible for me to swap the values.
PS: A friend of mine suggested that i should consider the bigger picture, and think in terms of concurrency and type immutability.
So do you have an explanation for this ? Thanks!
1) With a setter, the wrapper types would be mutable. Immutability is a good thing in many ways... threading, general understandability of the code etc. Personally I think it's a shame that Calendar and Date are mutable, for example.
In fact, your expansion of x++; isn't quite right - it uses Integer.valueOf which doesn't always create a new value. For example:
Integer x = 5;
x++;
Integer y = 5;
y++;
// This prints true
System.out.println(x == y); // Compare references
Only a limited range of Integer values are cached like this (the spec defines what values must behave this way, but allows for a wider range if the JRE wishes to do so)... but it does mean that it won't always be creating a new object.
2) Yes, Java doesn't have pass by reference. Frankly I very rarely find that to be a problem. How often do you really need to swap the values of variables?
这篇关于为什么基元的包装器类没有二传手?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
