Page 355	Table of Contents	Index	Page 357
	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

---

APPENDIX D. ENCAPSULATING STREAMS

Let us examine two generic functions, stream-accept and prompt-for-accept. The stream-
accept method on an ordinary stream calls prompt-for-accept. Now suppose that accepting-
values-stream specializes prompt-for-accept. If we now create a stream of type accepting-
values-stream (which we will designate A) which encapsulates an ordinary stream S, and then
call stream-accept on the stream E, it will trampoline to stream-accept on the stream S. The
desired behavior is for stream-accept to call the prompt-for-accept method on the stream E,
but instead what happens is that the prompt-for-accept method on the stream S is called.

In order to side-step this problem without attempting to solve a difficult general problem in
object-oriented programming, CLIM implementations may introduce a special variable, *original-
stream*, which is bound by trampoline functions to the original encapsulating stream. There-
fore, the stream-accept on the ordinary stream S will call prompt-for-accept on the value of
(or *original-stream* stream). This idiom only needs to be used in places where one stream
protocol function calls a second stream protocol function that some encapsulating stream spe-
cializes.

This "solution" does not solve the more general problem of multiple levels of encapsulation,
but the complete stream protocol provided by CLIM should allow implementors to avoid using
nested encapsulating streams.

=> *original-stream* [Variable]
This variable is bound by the trampoline methods on encapsulating streams to the encapsulating
stream, before the operation is delegated to the underlying, encapsulated stream.

---

Page 355	Table of Contents	Index	Page 357
	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