Java Reference
In-Depth Information
6
1
5
p u t t e r i n p u t i
Figure 8.5: Name space for symbols
putter
,
input
, and
i
library. The implementation details for hash tables are covered in most topics
on elementary data structures and are thoroughly discussed in [CLRS01].
At some point, a symbol table entry must represent the name of its symbol.
Each name is essentially a string of characters. However, by taking the fol-
lowing properties into consideration, an e
cient implementation of the name
space can be obtained:
•
The name of a symbol does not change during compilation. Thus, the
strings associated with symbol table names are immutable—once allo-
cated, they do not change.
•
Although scopes come and go, the symbol names persist throughout
compilation. Scope creation and deletion a
ff
ects the set of currently avail-
able symbols, obtainable through
. However, a scope's
symbols are not completely forgotten when the scope is abandoned.
Space must be reserved for the symbols at runtime, and the symbols
may require initialization. Thus, the symbols' strings occupy storage
that persists throughout compilation.
retrieve
S
ymbol
•
There can be great variance in the
length
of identifier names. Short
names—perhaps only a single character—are typically used for iteration
variables and temporaries. Global names in a large software system tend
to be descriptive and much longer in length. For example, the X win-
dowing system contains names such as VisibilityPartiallyObscured.
•
Unless an ordered list is maintained, comparisons of symbol names in-
volve only equality and inequality.
The above points argue in favor of one logical name space, as shown in Fig-
ure 8.5, in which names are inserted but never deleted.
