To make the preceding discussion more concrete, consider the following class definitions:
interface SomeInterface {
void op1();
};
class Base {
int baseInt;
void op2();
string baseString;
};
class Derived extends Base implements SomeInterface {
bool derivedBool;
string derivedString;
void op3();
double derivedDouble;
};
Note that Base and Derived have operations, and that Derived also implements the interface SomeInterface. Because marshaling of classes is concerned with state, not behavior, the operations op1, op2, and op3 are simply ignored during marshaling and the on-the-wire representation is as if the classes had been defined as follows:
class Base {
int baseInt;
string baseString;
};
class Derived extends Base {
bool derivedBool;
string derivedString;
double derivedDouble;
};
Suppose the sender marshals two instances of Derived (for example, as two in-parameters in the same request) with these member values:
First instance:
Member |
Type |
Value |
Marshaled Size (in bytes) |
|---|---|---|---|
|
|
|
4 |
|
|
|
6 |
|
|
|
1 |
|
|
|
7 |
|
|
|
8 |
Second instance:
Member |
Type |
Value |
Marshaled Size (in bytes) |
|---|---|---|---|
|
|
|
4 |
|
|
|
5 |
|
|
|
1 |
|
|
|
6 |
|
|
|
8 |
The sender arbitrarily assigns a non-zero identity to each instance. Typically, the sender will simply consecutively number the instances starting at 1. For this example, assume that the two instances have the identities 1 and 2. The marshaled representation for the two instances (assuming that they are marshaled immediately following each other) is shown below:
Marshaled Value |
Size in Bytes |
Type |
Byte offset |
|---|---|---|---|
|
4 |
|
0 |
|
1 |
|
4 |
|
10 |
|
5 |
|
4 |
|
15 |
|
1 |
|
19 |
|
7 |
|
20 |
|
8 |
|
27 |
|
1 |
|
35 |
|
7 |
|
36 |
|
4 |
|
43 |
|
4 |
|
47 |
|
6 |
|
51 |
|
1 |
|
57 |
|
14 |
|
58 |
|
4 |
|
72 |
|
1 |
|
76 |
|
4 |
|
77 |
|
1 |
|
81 |
|
1 |
|
82 |
|
4 |
|
83 |
|
1 |
|
87 |
|
6 |
|
88 |
|
8 |
|
94 |
|
1 |
|
102 |
|
1 |
|
103 |
|
4 |
|
104 |
|
4 |
|
108 |
|
5 |
|
112 |
|
1 |
|
117 |
|
1 |
|
118 |
|
4 |
|
119 |
|
1 |
|
123 |
Note that, because classes (like exceptions) are sent as a sequence of slices, the receiver of a class can slice off any derived parts of a class it does not understand. Also note that (as shown in the above table) each class instance contains three slices. The third slice is for the type ::Ice::Object, which is the base type of all classes. The class type ID ::Ice::Object has the number 3 in this example because it is the third distinct type ID that is marshaled by the sender. (See entries at byte offsets 58 and 118 in the above table.) All class instances have this final slice of type ::Ice::Object.
Marshaling a separate slice for ::Ice::Object dates back to Ice versions 1.3 and earlier. In those versions, classes carried a facet map that was marshaled as if it were defined as follows:
module Ice {
class Object;
dictionary<string, Object> FacetMap;
class Object {
FacetMap facets; // No longer exists
};
};
As of Ice version 1.4, this facet map is always empty, that is, the count of entries for the dictionary that is marshaled in the ::Ice::Object slice is always zero. If a receiver receives a class instance with a non-empty facet map, it must throw a MarshalException.
Note that if a class has no data members, a type ID and slice for that class is still marshaled. The byte count of the slice will be 4 in this case, indicating that the slice contains no data.