summaryrefslogtreecommitdiff
path: root/graphics/pgf/base/doc/text-en/pgfmanual-en-oo.tex
blob: 66ddbc6c4a7a9a68c21cb323171b83e9711c3f8d (plain)
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
% Copyright 2018 by Till Tantau
%
% This file may be distributed and/or modified
%
% 1. under the LaTeX Project Public License and/or
% 2. under the GNU Free Documentation License.
%
% See the file doc/generic/pgf/licenses/LICENSE for more details.


\section{Object-Oriented Programming}
\label{section-oop}

This section describes the |oo| module.

\begin{pgfmodule}{oo}
    This module defines a relatively small set of \TeX\ commands for defining
    classes, methods, attributes and objects in the sense of object-oriented
    programming.
\end{pgfmodule}

In this chapter it is assumed that you are familiar with the basics of a
typical object-oriented programming language like Java, C++ or Eiffel.


\subsection{Overview}

\TeX\ does not support object-oriented programming, presumably because it was
written at a time when this style of programming was not yet ``en vogue''. When
one is used to the object-oriented style of thinking, some programming
constructs in \TeX\ often seem overly complicated. The object-oriented
programming module of \pgfname\ may help here. It is written completely using
simple \TeX\ macros and is, thus, perfectly portable. This also means, however,
that it is not particularly fast (but not too slow either), so you should use
it only for non-time-critical things.

Basically, the oo-system supports \emph{classes} (in the object-oriented sense,
this has nothing to do with \LaTeX-classes), \emph{methods},
\emph{constructors}, \emph{attributes}, \emph{objects}, \emph{object
identities}, and (thanks to Sa\v so \v Zivanovi\'c) \emph{inheritance} and
\emph{overloading.}

The first step is to define a class, using the macro |\pgfooclass| (all normal
macros in \pgfname's object-oriented system start with |\pgfoo|). This macro
gets the name of a class and in its body a number of \emph{methods} are
defined. These are defined using the |\method| macro (which is defined only
inside such a class definition) and they look a bit like method definitions in,
say, Java. Object attributes are declared using the |\attribute| command, which
is also defined only inside a class definition.

Once a class has been defined, you can create objects of this class. Objects
are created using |\pgfoonew|. Such an object has many characteristics of
objects in a normal object-oriented programming language: Each object has a
\emph{unique identity}, so when you create another object, this object is
completely distinct from all other objects. Each object also has a set of
private attributes, which may change over time. Suppose, for instance, that we
have a |point| class. Then creating a new object (called an instance) of this
class would typically have an |x|-attribute and a |y|-attribute. These can be
changed over time. Creating another instance of the |point| class creates
another object with its own |x|- and |y|-attributes.

Given an object, you can call a method for this object. Inside the method the
attributes of the object for which the method is being called can be accessed.

The life of an object always ends with the end of the \TeX\ scope in which it
was created. However, changes to attribute values are not local to scopes, so
when you change an attribute anywhere, this change persists till the end of the
life of the object or until the attribute is changed again.


\subsection{A Running Example: The Stamp Class}

As a running example we will develop a |stamp| class and |stamp| objects. The
idea is that a stamp object is able to ``stamp something'' on a picture. This
means that a stamp object has an attribute storing the ``stamp text'' and there
is a method that asks the object to place this text somewhere on a canvas. The
method can be called repeatedly and there can be several different stamp
objects, each producing a different text. Stamp objects can either be created
dynamically when needed or a library might define many such objects in an outer
scope.

Such stamps are similar to many things present in \pgfname\ such as arrow tips,
patterns, or shadings and, indeed, these could all have been implemented in
this object-oriented fashion (which might have been better, but the
object-oriented subsystem is a fairly new addition to \pgfname).


\subsection{Classes}

We start with the definition of the |stamp| class. This is done using the
|\pgfooclass| macro:

\begin{command}{\pgfooclass\opt{|(|\meta{list of superclasses}|)|}\marg{class name}\marg{body}}
    This command defines a class named \meta{class name}. The name of the class
    can contain spaces and most other characters, but no periods. So, valid
    class names are |MyClass| or |my class| or |Class_C++_emulation??1|. The
    \meta{list of superclasses} is optional just like the parenthesis around
    it.

    The \meta{body} is actually just executed, so any normal \TeX-code is
    permissible here. However, while the \meta{body} is being executed, the
    macros |\method| and |\attribute| are set up so that they can be used to
    define methods and attributes for this class (the original meanings are
    restored afterward).

    The definition of a class is local to the scope where the class has been
    defined.
    %
\begin{codeexample}[code only]
\pgfooclass{stamp}{
  % This is the class stamp

  \attribute text;
  \attribute rotation angle=20;

  \method stamp(#1) { % The constructor
    ...
  }

  \method apply(#1,#2) { % Causes the stamp to be shown at coordinate (#1,#2)
    ...
  }
}

% We can now create objects of type "stamp"
\end{codeexample}

    Concerning the list of base classes, the Method Resolution Order
    (\textsc{mro}) is computed using the C3 algorithm also used in Python, v2.3
    and higher. The linearization computed by the algorithm respects both
    local precedence ordering and monotonicity. Resolution of both methods and
    attributes depends on the \textsc{mro}: when a method method name is called
    on an object of class $C$, the system invokes method method name from the
    first class in the \textsc{mro} of $C$ which defines method method name;
    when an object is created, each attribute |attr| is initialized to the
    value specified in the first class in the \textsc{mro} of $C$ which
    declares attribute |attr|.
\end{command}

The \meta{body} of a class usually just consists of calls to the macros
|\attribute| and |\method|, which will be discussed in more detail in later
sections.


\subsection{Objects}

Once a class has been declared, we can start creating objects for this class.
For this the |\pgfoonew| command can be used, which has a peculiar syntax:

\begin{command}{\pgfoonew\opt{\meta{object handle or attribute}|=|}|new |\meta{class name}|(|\meta{constructor arguments}|)|}
    Causes a new object to be created. The class of the object will be
    \meta{class name}, which must previously have been declared using
    |\pgfooclass|. Once the object has been created, the constructor method of
    the object will be called with the parameter list set to \meta{constructor
    arguments}.

    The resulting object is stored internally and its lifetime will end exactly
    at the end of the current scope.

    Here is an example in which three stamp objects are created.
    %
\begin{codeexample}[code only]
\pgfoonew \firststamp=new stamp()
\pgfoonew \secondstamp=new stamp()
{
  \pgfoonew \thirdstamp=new stamp()
  ...
}
% \thirdstamp no longer exists, but \firststamp and \secondstamp do
% even if you try to store \thirdstamp in a global variable, trying
% to access it will result in an error.
\end{codeexample}

    The optional \meta{object handle or attribute} can either be an
    \meta{object handle} or an \meta{attribute}. When an \meta{object handle}
    is given, it must be a normal \TeX\ macro name that will ``point'' to the
    object (handles are discussed in more detail in
    Section~\ref{section-identities}). You can use this macro to call methods
    of the object as discussed in the following section. When an
    \meta{attribute} is given, it must be given in curly braces (the curly
    braces are used to detect the presence of an attribute). In this case, a
    handle to the newly created object is stored in this attribute.
    %
\begin{codeexample}[code only]
\pgfooclass{foo}
{
  \attribute stamp obj;
  \attribute another object;

  \method foo() {
    \pgfoonew{stamp obj}=new stamp()
    \pgfoonew{another object}=new bar()
  }
  ...
}
\end{codeexample}
    %
\end{command}

\begin{command}{\pgfoogc}
    This command causes the ``garbage collector'' to be invoked. The job of
    this garbage collector is to free the global \TeX-macros that are used by
    ``dead'' objects (objects whose life-time has ended). This macro is called
    automatically after every scope in which an object has been created, so you
    normally do not need to call this macro yourself.
\end{command}


\subsection{Methods}

Methods are defined inside the body of classes using the following command:

\begin{command}{\method \meta{method name}|(|\meta{parameter list}|)|\marg{method body}}
    This macro, which is only defined inside a class definition, defines a new
    method named \meta{method name}. Just like class names, method names can
    contain spaces and other characters, so \meta{method names} like
    |put_stamp_here| or |put stamp here| are both legal.

    Three method names are special: First, a method having either the same name
    as the class or having the name |init| is called the \emph{constructor} of
    the class. There are (currently) no destructors; objects simply become
    ``undefined'' at the end of the scope in which they have been created. The
    other two methods are called |get id| and |get handle|, which are always
    automatically defined and which you cannot redefine. They are discussed in
    Section~\ref{section-identities}.

    Overloading of methods by differing numbers of parameters is not possible,
    that is, it is illegal to have two methods inside a single class with the
    same name (despite possibly different parameter lists). However, two
    different classes may contain a method with the same name, that is, classes
    form namespaces for methods. Also, a class can (re)implement a method from
    a superclass.

    The \meta{method name} must be followed by a \meta{parameter list} in
    parentheses, which must be present even when the \meta{parameter list} is
    empty. The \meta{parameter list} is actually a normal \TeX\ parameter list
    that will be matched against the parameters inside the parentheses upon
    method invocation and, thus, could be something like |#1#2 foo #3 bar.|,
    but a list like |#1,#2,#3| is more customary. By setting the parameter list
    to just |#1| and then calling, say, |\pgfkeys{#1}| at the beginning of a
    method, you can implement Objective-C-like named parameters.

    When a method is called, the \meta{body} of the method will be executed.
    The main difference to a normal macro is that while the \meta{body} is
    executed, a special macro called |\pgfoothis| is set up in such a way that
    it references the object for which the method is executed.
\end{command}

In order to call a method for an object, you first need to create the object
and you need a handle for this object. In order to invoke a method for this
object, a special syntax is used that is similar to Java or C++ syntax:

\begin{pgfmanualentry}
    \pgfmanualentryheadline{\meta{object handle}\opt{|.|\meta{super class}}|.|\meta{method name}|(|\meta{parameters}|)|}%
    \pgfmanualbody
    This causes the method \meta{method name} to be called for the object
    referenced by the \meta{object handle}. The method is the one defined in
    the class of the object or, if it is not defined there, the method defined
    in the superclasses of the object's class (if there are several
    superclasses that define the same method, the method resolution order is
    used to determine which one gets called). If the optional \meta{super
    class} is specified, the method implementation of that class will be used
    rather than the implementation in the object's class. The \meta{parameters}
    are matched against the parameters of the method and, then, the method body
    is executed. The execution of the method body is \emph{not} done inside a
    scope, so the effects of a method body persist.
    %
\begin{codeexample}[code only]
\pgfooclass{stamp}{
  % This is the class stamp

  \method stamp() { % The constructor
  }

  \method apply(#1,#2) { % Causes the stamp to be shown at coordinate (#1,#2)
    % Draw the stamp:
    \node [rotate=20,font=\huge] at (#1,#2) {Passed};
  }
}

\pgfoonew \mystamp=new stamp()

\begin{tikzpicture}
  \mystamp.apply(1,2)
  \mystamp.apply(3,4)
\end{tikzpicture}
\end{codeexample}

    Inside a method, you can call other methods. If you have a handle for
    another object, you can simply call it in the manner described above. In
    order to call a method of the current object, you can use the special
    object handle |\pgfoothis|.

    \begin{command}{\pgfoothis}
        This object handle is well-defined only when a method is being executed.
        There, it is then set to point to the object for which the method is
        being called, which allows you to call another method for the same
        object.
        %
\begin{codeexample}[code only]
\pgfooclass{stamp}{
  % This is the class stamp

  \method stamp() {}

  \method apply(#1,#2) {
    \pgfoothis.shift origin(#1,#2)

    % Draw the stamp:
    \node [rotate=20,font=\huge] {Passed};
  }

  % Private method:
  \method shift origin(#1,#2) {
    \tikzset{xshift=#1,yshift=#2}
  }
}
\end{codeexample}
    \end{command}
\end{pgfmanualentry}

\begin{command}{\pgfoosuper|(|\meta{class},\meta{object handle}|).|\meta{method name}|(|\meta{arguments}|)|}
    This macro gives you finer control over which method gets invoked in case
    of multiple inheritance. This macro calls \meta{method name} of the object
    specified by \meta{object handle}, but which implementation of the method
    is called is determined as follows: it will be the implementation in the
    first class (in the method resolution order) after \meta{class} that
    defines \meta{method name}.
\end{command}


\subsection{Attributes}

Every object has a set of attributes, which may change over time. Attributes
are declared using the |\attribute| command, which, like the |\method| command,
is defined only inside the scope of |\pgfooclass|. Attributes can be modified
(only) by methods. To take the |stamp| example, an attribute of a |stamp|
object might be the text that should be stamped when the |apply| method is
called.

When an attribute is changed, this change is \emph{not} local to the current
\TeX\ group. Changes will persist till the end of the object's life or until
the attribute is changed once more.

To declare an attribute you should use the |\attribute| command:
%
\begin{command}{\attribute \meta{attribute name}\opt{|=|\meta{initial value}}|;|}
    This command can only be given inside the body of an |\pgfooclass| command.
    It declares the attribute named \meta{attribute name}. This name, like
    method or class names, can be quite arbitrary, but should not contain
    periods. Valid names are |an_attribute?| or |my attribute|.

    You can optionally specify an \meta{initial value} for the attribute; if
    none is given, the empty string is used automatically. The initial value is
    the value that the attribute will have just after the object has been
    created and before the constructor is called.
    %
\begin{codeexample}[code only]
\pgfooclass{stamp}{
  % This is the class stamp

  \attribute text;
  \attribute rotation angle = 20;

  \method stamp(#1) {
    \pgfooset{text}{#1} % Set the text
  }

  \method apply(#1,#2) {
    \pgfoothis.shift origin(#1,#2)

    % Draw the stamp:
    \node [rotate=\pgfoovalueof{rotation angle},font=\huge]
      {\pgfoovalueof{text}};
  }

  \method shift origin(#1,#2) { ... }

  \method set rotation (#1) {
    \pgfooset{rotation angle}{#1}
  }
}
\end{codeexample}
    %
\end{command}

Attributes can be set and read only inside methods, it is not possible to do so
using an object handle. Spoken in terms of traditional object-oriented
programming, attributes are always private. You need to define getter and
setter methods if you wish to read or modify attributes.

Reading and writing attributes is not done using the ``dot-notation'' that is
used for method calls. This is mostly due to efficiency reasons. Instead, a set
of special macros is used, all of which can \emph{only be used inside methods}.

\begin{command}{\pgfooset\marg{attribute}\marg{value}}
    Sets the \meta{attribute} of the current object to \meta{value}.
    %
\begin{codeexample}[code only]
\method set rotation (#1) {
  \pgfooset{rotation angle}{#1}
}
\end{codeexample}
    %
\end{command}

\begin{command}{\pgfooeset\marg{attribute}\marg{value}}
    Performs the same action as |\pgfooset| but in an |\edef| full expansion
    context.
\end{command}

\begin{command}{\pgfooappend\marg{attribute}\marg{value}}
    This method adds the given \meta{value} to the \meta{attribute} at the end.
\end{command}

\begin{command}{\pgfooprefix\marg{attribute}\marg{value}}
    This method adds the given \meta{value} to the \meta{attribute} at the
    beginning.
\end{command}

\begin{command}{\pgfoolet\marg{attribute}\marg{macro}}
    Sets the \meta{attribute} of the current value to the current value of
    \meta{macro} using \TeX's |\let| command.
    %
\begin{codeexample}[code only]
\method foo () {
  \pgfoolet{my func}\myfunc
  % Changing \myfunc now has no effect on the value of attribute my func
}
\end{codeexample}
    %
\end{command}

\begin{command}{\pgfoovalueof\marg{attribute}}
    Expands (eventually) to the current value of \meta{attribute} of the
    current object.
    %
\begin{codeexample}[code only]
\method apply(#1,#2) {
  \pgfoothis.shift origin(#1,#2)

  \node [rotate=\pgfoovalueof{rotation angle},font=\huge]
    {\pgfoovalueof{text}};
}
\end{codeexample}
    %
\end{command}

\begin{command}{\pgfooget\marg{attribute}\marg{macro}}
    Reads the current value of \meta{attribute} and stores the result in
    \meta{macro}.
    %
\begin{codeexample}[code only]
...
  \method get rotation (#1) {
    \pgfooget{rotation angle}{#1}
  }
...

\mystamp.get rotation(\therotation)
``\therotation'' is now ``20'' (or whatever).
\end{codeexample}
    %
\end{command}


\subsection{Identities}
\label{section-identities}

Every object has a unique identity, which is simply an integer. It is possible
to retrieve the object id using the |get id| method (discussed below), but
normally you will not need to do so because the id itself cannot be used to
access an object. Rather, you access objects via their methods and these, in
turn, can only be called via object handles.

Object handles can be created in four ways:
%
\begin{enumerate}
    \item Calling |\pgfoonew|\meta{object handle}|=...| will cause \meta{object
        handle} to be a handle to the newly created object.
    \item Using |\let| to create an alias of an existing object handle: If
        |\mystamp| is a handle, saying |\let\myotherstamp=\mystamp| creates a
        second handle to the same object.
    \item |\pgfooobj|\marg{id} can be used as an object handle to the object
        with the given \meta{id}.
    \item Using the |get handle| method to create a handle to a given object.
\end{enumerate}

Let us have a look at the last two methods.

\begin{command}{\pgfooobj\marg{id}}
    Provided that \meta{id} is the id of an existing object (an object whose
    life-time has not expired), calling this command yields a handle to this
    object. The handle can then be used to call methods:
    %
\begin{codeexample}[code only]
% Create a new object:
\pgfoonew \mystamp=new stamp()

% Get the object's id and store it in \myid:
\mystamp.get id(\myid)

% The following two calls have the same effect:
\mystamp.apply(1,1)
\pgfooobj{\myid}.apply(1,1)
\end{codeexample}
    %
\end{command}

The |get id| method can be used to retrieve the id of an object. This method is
predefined for every class and you should not try to define a method of this
name yourself.

\begin{predefinedmethod}{get id(\meta{macro})}
    Calling \meta{obj}|.get id(|\meta{macro}|)|  stores the id \meta{obj} in
    \meta{macro}. This is mainly useful when you wish to store an object for a
    longer time and you cannot guarantee that any handle that you happen to
    have for this object will be available later on.

    The only way to use the retrieved id later on is to call |\pgfooobj|.

    Different object that are alive (that are still within the scope in which
    they were created) will always have different ids, so you can use the id to
    test for equality of objects. However, after an object has been destroyed
    because its scope has ended, the same id may be used again for newly
    created objects.

    Here is a typical application where you need to call this method: You wish
    to collect a list of objects for which you wish to call a specific method
    from time to time. For the collection process you wish to offer a macro
    called |\addtoobjectlist|, which takes an object handle as parameter. It is
    quite easy to store this handle somewhere, but a handle is, well, just a
    handle. Typically, shortly after the call to |\addtoobjectlist| the handle
    will no longer be valid or even exist, even though the object still exists.
    In this case, you wish to store the object id somewhere instead of the
    handle. Thus, for the object passed to |\addtoobjectlist| you call the
    |get id| method and store the resulting id, rather than the handle.
\end{predefinedmethod}

There is a second predefined method, called |get handle|, which is also used to
create object handles.

\begin{predefinedmethod}{get handle(\marg{macro name})}
    Calling this method for an object will cause \meta{macro name} to become a
    handle to the given object. For any object handle |\obj| -- other than
    |\pgfoothis| -- the following two have the same effect:
    %
    \begin{enumerate}
        \item |\let|\meta{macro name}|=\obj|
        \item |\obj.get handle(|\meta{macro name}|)|
    \end{enumerate}

    The first method is simpler and faster. However, for |\pgfoothis| there is
    a difference: The call |\pgfoothis.get handle(|\meta{macro name}|)| will
    cause \meta{macro name} to be an object handle to the current object and
    will persist to be so even after the method is done. By comparison,
    |\let|\meta{macro name}|=\pgfoothis| causes |\obj| to be the same as the
    very special macro |\pgfoothis|, so |\obj| will always refer to the current
    object, which may change over time.
\end{predefinedmethod}


\subsection{The Object Class}
\label{section-object}

The object-oriented module predefines a basic class |object| that can be used
as a base class in different context.

\begin{ooclass}{object}
    This class current only implements one method:

    \begin{method}{copy(\meta{handle})}
        Creates a new object and initializes the values of its (declared)
        attributes to the values of the original. The method takes one
        argument: a control sequence which receives the handle of the copy.
    \end{method}
\end{ooclass}


\subsection{The Signal Class}
\label{section-signals}

In addition to the basic mechanism for defining and using classes and object,
the class |signal| is predefined. It implements a so-called signal--slot
mechanism.

\begin{ooclass}{signal}
    This class is used to implement a simple signal--slot mechanism. The idea
    is the following: From time to time special things happen about which a
    number of objects need to be informed. Different things can happen and
    different object will be interested in these things. A |signal| object can
    be used to signal that such special things of a certain kind have happened.
    For example, one signal object might be used to signal the event that ``a
    page has been shipped out''. Another signal might be used to signal that
    ``a figure is about to be typeset'', and so on.

    Objects can ``tune in'' to signals. They do so by \emph{connecting} one of
    their methods (then called a \emph{slot}) to the signal. Then, whenever the
    signal is \emph{emitted}, the method of the connected object(s) get called.
    Different objects can connect different slots to the same signal as long as
    the argument lists will fit. For example, the object that is used to signal
    the ``end of page has been reached'' might emit signals that have, say, the
    box number in which the finished page can be found as a parameter
    (actually, the finished page is always in box 255). Then one object could
    connect a method |handle page(#1)| to this signal, another might connect
    the method |emergency action(#1)| to this signal, and so on.

    Currently, it is not possible to ``unregister'' or ``detach'' a slot from a
    signal, that is, once an object has been connect to a signal, it will
    continue to receive emissions of this signal till the end of the life-time
    of the signal. This is even true when the object no longer exists (but the
    signal does), so care must be taken that signal objects are always created
    after the objects that are listening to them.

    \begin{method}{signal()}
        The constructor does nothing.
    \end{method}

    \begin{method}{connect(\meta{object handle},\meta{method name})}
        This method gets an \meta{object handle} as parameter and a
        \meta{method name} of this object. It will queue the object-method pair
        in an internal list and each time the signal emits something, this
        object's method is called.

        Be careful not to pass |\pgfoothis| as \meta{object handle}. This would
        cause the signal object to connect to itself. Rather, if you wish to
        connect a signal to a method of the current object you first need to
        create an alias using the |get handle| method:
        %
\begin{codeexample}[code only]
\pgfooclass{some class}{
  \method some class() {
    \pgfoothis.get handle(\me)
    \somesignal.connect(\me,foo)
    \anothersignal.connect(\me,bar)
  }
  \method foo () {}
  \method bar (#1,#2) {}
}
\pgfoonew \objA=new some class()
\pgfoonew \objB=new some class()
\end{codeexample}
    \end{method}

    \begin{method}{emit(\meta{arguments})}
        This method emits a signal to all connected slots. This means that for
        all objects that have previously been connected via a call of
        |connect|, the method (slot) that was specified during the call of
        |connect| is invoked with given \meta{arguments}.
        %
\begin{codeexample}[code only]
\anothersignal.emit(1,2)
% will call \objA.bar(1,2) and \objB.bar(1,2)
\end{codeexample}
    \end{method}
\end{ooclass}


\subsection{Implementation Notes}

For the curious, here are some notes on how the oo-system is implemented:
%
\begin{itemize}
    \item There is an object id counter that gets incremented each time an
        object is created. However, this counter is local to the current scope,
        which means that it is reset at the end of each scope, corresponding to
        the fact that at the end of a scope all objects created in this scope
        become invalid. Newly created objects will then have the same id as
        ``deleted'' objects.
    \item Attributes are stored globally. For each attribute of each object
        there is a macro whose name is composed of the object's id and the
        attribute name. Changes to object attributes are always global.
    \item A call to the garbage collector causes a loop to be executed that
        tries to find objects whose object number is larger than the current
        maximum alive objects. The global attributes of these objects are then
        freed (set to |\relax|) by calling a special internal method of these
        (dead) objects.

        The garbage collector is automatically called after each group in
        which an object was created using |\aftergroup|.
    \item When a method is called, before the method call some code is executed
        that sets a global counter storing the current object id to the object
        id of the object being called. After the method call some code is
        inserted that restores the global counter to its original value. This
        is done without scopes, so some tricky |\expandafter| magic is needed.
        Note that, because of this process, you cannot use commands like
        |\pgfutil@ifnextchar| at the end of a method.
    \item An object handle contains just the code to set up and restore the
        current object number to the number of the object being called.
\end{itemize}