► |  | The Racket Reference

1 | Language Model
2 | Notation for Documentation
3 | Syntactic Forms
4 | Datatypes
5 | Structures
6 | Classes and Objects
7 | Units
8 | Contracts
9 | Pattern Matching
10 | Control Flow
11 | Concurrency and Parallelism
12 | Macros
13 | Input and Output
14 | Reflection and Security
15 | Operating System
16 | Memory Management
17 | Unsafe Operations
18 | Running Racket
| Bibliography
| Index

▼ | 6 | Classes and Objects

6.1 | Creating Interfaces
6.2 | Creating Classes
6.3 | Creating Objects
6.4 | Field and Method Access
6.5 | Mixins
6.6 | Traits
6.7 | Object and Class Contracts
6.8 | Object Equality and Hashing
6.9 | Object Serialization
6.10 | Object Printing
6.11 | Object, Class, and Interface Utilities
6.12 | Surrogates

On this page:

define-serializable-class*
define-serializable-class
externalizable<%>

top ← prev up next →

#### 6.9`` Object Serialization

> > syntax

> > (define-serializable-class* class-id superclass-expr
> > (interface-expr ...)
> > class-clause ...)

Binds class-id to a class, where superclass-expr, the interface-exprs, and the class-clauses are as in class*.

This form can only be used at the top level, either within a module or outside. The class-id identifier is bound to the new class, and deserialize-info:class-id is also defined; if the definition is within a module, then the latter is provided from a deserialize-info submodule via module+.

Serialization for the class works in one of two ways:

- If the class implements the built-in interface externalizable<%>, then an object is serialized by calling its externalize method; the result can be anything that is serializable (but, obviously, should not be the object itself). Deserialization creates an instance of the class with no initialization arguments, and then calls the object’s internalize method with the result of externalize (or, more precisely, a deserialized version of the serialized result of a previous call).

  To support this form of serialization, the class must be instantiable with no initialization arguments. Furthermore, cycles involving only instances of the class (and other such classes) cannot be serialized.

- If the class does not implement externalizable<%>, then every superclass of the class must be either serializable or transparent (i.e,. have #f as its inspector). Serialization and deserialization are fully automatic, and may involve cycles of instances.

  To support cycles of instances, deserialization may create an instance of the call with all fields as the undefined value, and then mutate the object to set the field values. Serialization support does not otherwise make an object’s fields mutable.

In the second case, a serializable subclass can implement externalizable<%>, in which case the externalize method is responsible for all serialization (i.e., automatic serialization is lost for instances of the subclass). In the first case, all serializable subclasses implement externalizable<%>, since a subclass implements all of the interfaces of its parent class.

In either case, if an object is an immediate instance of a subclass (that is not itself serializable), the object is serialized as if it was an immediate instance of the serializable class. In particular, overriding declarations of the externalize method are ignored for instances of non-serializable subclasses.

> > syntax

> > (define-serializable-class class-id superclass-expr
> > class-clause ...)

Like define-serializable-class*, but without interface expressions (analogous to class).

> interface

> externalizable<%> : interface?

The externalizable<%> interface includes only the externalize and internalize methods. See define-serializable-class* for more information.

top ← prev up next →