► |  | 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:

interface
interface*

top ← prev up next →

#### 6.1`` Creating Interfaces

> > > Classes and Objects in The Racket Guide introduces classes, objects, and interfaces.

> > syntax

> > (interface (super-interface-expr ...) name-clause ...)

> name-clause |  | = |  | id
> |  | | |  | (id contract-expr)

Produces an interface. The ids must be mutually distinct.

Each super-interface-expr is evaluated (in order) when the interface expression is evaluated. The result of each super-interface-expr must be an interface value, otherwise the exn:fail:object exception is raised. The interfaces returned by the super-interface-exprs are the new interface’s superinterfaces, which are all extended by the new interface. Any class that implements the new interface also implements all of the superinterfaces.

The result of an interface expression is an interface that includes all of the specified ids, plus all identifiers from the superinterfaces. Duplicate identifier names among the superinterfaces are ignored, but if a superinterface contains one of the ids in the interface expression, the exn:fail:object exception is raised. A given id may be paired with a corresponding contract-expr.

If no super-interface-exprs are provided, then the derivation requirement of the resulting interface is trivial: any class that implements the interface must be derived from object%. Otherwise, the implementation requirement of the resulting interface is the most specific requirement from its superinterfaces. If the superinterfaces specify inconsistent derivation requirements, the exn:fail:object exception is raised.

Examples:

> (define file-interface<%>
> (interface () open close read-byte write-byte))

> (define directory-interface<%>
> (interface (file-interface<%>)
> [file-list (->m (listof (is-a?/c file-interface<%>)))]
> parent-directory))

> > syntax

> > (interface* (super-interface-expr ...)
> > ([property-expr val-expr] ...)
> > name-clause ...)

> name-clause |  | = |  | id
> |  | | |  | (id contract-expr)

Like interface, but also associates to the interface the structure-type properties produced by the property-exprs with the corresponding val-exprs.

Whenever the resulting interface (or a sub-interface derived from it) is explicitly implemented by a class through the class* form, each property is attached with its value to a structure type that instantiated by instances of the class. Specifically, the property is attached to a structure type with zero immediate fields, which is extended to produce the internal structure type for instances of the class (so that no information about fields is accessible to the structure type property’s guard, if any).

Example:

> (define i<%> (interface* () ([prop:custom-write
> (lambda (obj port mode) (void))])
> method1 method2 method3))

top ← prev up next →