Page 6	Table of Contents	Index	Page 8
	Chapters
	1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 A, B, C, D, E

---

CHAPTER 2. CONVENTIONS

usually via setf accessors.

In CLIM, object immutability is maintained at the class level. Throughout this specification,
the immutability or mutability of a class will be explicitly specified.

Some immutable classes also allow interning. A class is said to be interning if it guarantees
that two instances that are equivalent will always be eq. For example, if the class color were
interning, calling make-rgb-color twice with the same arguments would return eq values. CLIM
does not specify that any class is interning, however all immutable classes are allowed to be
interning at the discretion of the implementation.

In some rare cases, CLIM will modify objects that are members of immutable classes. Such
objects are referred to as being volatile. Extreme care must be take with volatile objects. This
specification will note whenever some object that is part of the API is volatile.

2.4.1 Behavior of Interfaces

In this specification, any interfaces that take or return mutable objects can be classified in a few
different ways.

Most functions do not capture their mutable input objects, that is, these functions will either
not store the objects at all, or will copy any mutable objects before storing them, or perhaps
store only some of the components of the objects. Later modifications to those objects will not
affect the internal state of CLIM.

Some functions may capture their mutable input objects. That is, it is unspecified as to whether
a CLIM implementation will or will not capture the mutable inputs to some function. For such
functions, programmers should assume that these objects will be captured and must not modify
these objects capriciously. Furthermore, it is unspecifed what will happen if these objects are
later modified.

Some programmers might choose to create a mutable subclass of an immutable class. If CLIM
captures an object that is a member of such a class, it is unspecified what will happen if the
programmer later modifies that object. If a programmer passes such an object to a CLIM
function that may capture its inputs, he is responsible for either first copying the object or
ensuring that the object does not change later.

Some functions that return mutable objects are guaranteed to create fresh outputs. These objects
can be modified without affecting the internal state of CLIM.

Functions that return mutable objects that are not fresh objects fall into two categories: those
that return read-only state, and those that return read/write state. If a function returns read-
only state, programmers must not modify that object; doing so might corrupt the state of CLIM.
If a function returns read/write state, the modification of that object is part of CLIM's interface,
and programmers are free to modify the object in ways that "make sense".

---

Page 6	Table of Contents	Index	Page 8
	Chapters
	1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 A, B, C, D, E