Object type (object-oriented programming)

In computer science, an object type (a.k.a. wrapping object) is a datatype that is used in object-oriented programming to wrap a non-object type to use it more like a dynamic object.

Some object-oriented programming languages make a distinction between reference and value types, often referred to as objects and non-objects on platforms where complex value types don't exist, for reasons such as runtime efficiency and syntax or semantic issues. For example, Java has primitive wrapper classes corresponding to each primitive type:

Integer

|

and

int

|

Character

|

and

char

|

Float

|

and

float

|

, etc. Languages like C++ have little or no notion of reference type.

## Contents

* 1 Boxing
* 1.1 Autoboxing
* 1.2 Unboxing
* 1.3 Type helpers
* 2 References

## Boxing

Boxing, otherwise known as wrapping, is the process of placing a primitive type within an object so that the primitive can be used as a reference object. For example, in Java, a

LinkedList

|

can change its size, but an array must have a fixed size. One might desire to have a

LinkedList

|

int

|

, but the

LinkedList

|

class only lists references to dynamic objects—it cannot list primitive types, which are value types.

To circumvent this,

int

|

can be boxed into

Integer

|

, which are dynamic objects, and then added to a

LinkedList

|

Integer

|

. (Using generic parameterized types introduced in J2SE 5.0, this type is represented as

LinkedList<Integer>

|

.) On the other hand, C# has no primitive wrapper classes, but allows boxing of any value type, returning a generic `Object` reference. In Objective-C, any primitive value can be prefixed by a Template:ObjC to make an Template:ObjC out of it (e.g. Template:ObjC or Template:ObjC). This allows for adding them in any of the standard collections, such as an Template:ObjC.

The boxed object is always a copy of the value object, and is usually immutable. Unboxing the object also returns a copy of the stored value. Repeated boxing and unboxing of objects can have a severe performance impact, because boxing dynamically allocates new objects and unboxing (if the boxed value is no longer used) then makes them eligible for garbage collection. However, modern garbage collectors such as the default Java HotSpot garbage collector can more efficiently collect short-lived objects, so if the boxed objects are short-lived, the performance impact may not be severe.

In some languages, there is a direct equivalence between an unboxed primitive type and a reference to an immutable, boxed object type. In fact, it is possible to substitute all the primitive types in a program with boxed object types. Whereas assignment from one primitive to another will copy its value, assignment from one reference to a boxed object to another will copy the reference value to refer to the same object as the first reference. However, this will not cause any problems, because the objects are immutable, so there is semantically no real difference between two references to the same object or to different objects (unless you look at physical equality). For all operations other than assignment, such as arithmetic, comparison, and logical operators, one can unbox the boxed type, perform the operation, and re-box the result as needed. Thus, it is possible to not store primitive types at all.

### Autoboxing

Autoboxing is the term for getting a reference type out of a value type just through type conversion (either implicit or explicit). The compiler automatically supplies the extra source code that creates the object.

For example, in versions of Java prior to J2SE 5.0, the following code did not compile:

Integer i = new Integer(9);
Integer i = 9; // error in versions prior to 5.0!

Compilers prior to 5.0 would not accept the last line.

Integer

|

are reference objects, on the surface no different from

List

|

Object

|

, and so forth. To convert from an

int

|

to an

Integer

|

, one had to "manually" instantiate the Integer object. As of J2SE 5.0, the compiler will accept the last line, and automatically transform it so that an Integer object is created to store the value

|

.[1] This means that, from J2SE 5.0 on, something like

Integer c = a + b

|

, where

|

and

|

are

Integer

|

themselves, will compile now - a and b are unboxed, the integer values summed up, and the result is autoboxed into a new

Integer

|

, which is finally stored inside variable

|

. The equality operators cannot be used this way, because the equality operators are already defined for reference types, for equality of the references; to test for equality of the value in a boxed type, one must still manually unbox them and compare the primitives, or use the

Objects.equals

|

method.

Another example: J2SE 5.0 allows the programmer to treat a collection (such as a

LinkedList

|

) as if it contained

int

|

values instead of

Integer

|

objects. This does not contradict what was said above: the collection still only contains references to dynamic objects, and it cannot list primitive types. It cannot be a

LinkedList<int>

|

, but it must be a

LinkedList<Integer>

|

instead. However, the compiler automatically transforms the code so that the list will "silently" receive objects, while the source code only mentions primitive values. For example, the programmer can now write

list.add(3)

|

and think as if the

int

|

|

were added to the list; but, the compiler will have actually transformed the line into

list.add(new Integer(3))

|

### Unboxing

Unboxing refers to getting the value that is associated to a given object, just through type conversion (either implicit or explicit). The compiler automatically supplies the extra source code that retrieves the value out of that object, either by invoking some method on that object, or by other means.

For example, in versions of Java prior to J2SE 5.0, the following code did not compile:

Integer k = new Integer(4);
int l = k.intValue(); // always okay
int m = k;            // would have been an error, but okay now

C# doesn't support automatic unboxing in the same meaning as Java, because it doesn't have a separate set of primitive types and object types. All types that have both primitive and object version in Java, are automatically implemented by the C# compiler as either primitive (value) types or object (reference) types.

In both languages, automatic boxing does not downcast automatically, i.e. the following code won't compile:

C#:

int i = 42;
object o = i;         // box
int j = o;            // unbox (error)
Console.WriteLine(j); // unreachable line, author might have expected output "42"

Java:

int i = 42;
Object o = i;          // box
int j = o;             // unbox (error)
System.out.println(j); // unreachable line, author might have expected output "42"

### Type helpers

Modern Object Pascal has yet another way to perform operations on simple types, close to boxing, called type helpers in FreePascal or record helpers in Delphi and FreePascal in Delphi mode.
The dialects mentioned are Object Pascal compile-to-native languages, and so miss some of the features that C# and Java can implement. Notably run-time type inference on strongly typed variables.
But the feature is related to boxing.
It allows the programmer to use constructs like

{$ifdef fpc}{$mode delphi}{$endif}
uses sysutils;  // this unit contains wraps for the simple types
var
x:integer=100;
s:string;
begin
s:= x.ToString;
writeln(s);
end.

## References

1. ↑ oracle.com Java language guide entry on autoboxing

* v
* t
* e

Data types

Uninterpreted|

* Bit
* Byte
* Trit
* Tryte
* Word
* Bit array

Numeric|

* Arbitrary-precision or bignum
* Complex
* Decimal
* Fixed point
* Floating point
* Double precision
* Extended precision
* Long double
* Octuple precision
* Quadruple precision
* Single precision
* Reduced precision
* Minifloat
* Half precision
* bfloat16
* Integer
* signedness
* Interval
* Rational

Pointer|

* Address
* physical
* virtual
* Reference

Text|

* Character
* String
* null-terminated

Composite|

* Algebraic data type
* generalized
* Array
* Associative array
* Class
* Dependent
* Equality
* Inductive
* Intersection
* List
* Object
* metaobject
* Option type
* Product
* Record or Struct
* Refinement
* Set
* Union
* tagged

Other|

* Boolean
* Bottom type
* Collection
* Enumerated type
* Exception
* Function type
* Opaque data type
* Recursive data type
* Semaphore
* Stream
* Top type
* Type class
* Unit type
* Void

Related
topics|

* Abstract data type
* Data structure
* Generic
* Kind
* metaclass
* Parametric polymorphism
* Primitive data type
* Protocol
* interface
* Subtyping
* Type constructor
* Type conversion
* Type system
* Type theory

See also platform-dependent and independent units of information

0.00

(0 votes)

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Object_type_(object-oriented_programming)&oldid=206929"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template