summaryrefslogtreecommitdiff
path: root/naming_context.mdwn
blob: 2968b0a560a712f08cafdddecd96e2c7ebc74b0e (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
[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

Names are bindings to objects, however, to find an object
given a name, the relation must be looked up in a
*naming context*.

A problem with using strings as names is
that it is very easy to lose track of the correct naming
context.  This is one of the problem with [[passive
translators|hurd/translator]]:
a passive translator is a string.  When the node is accessed
on which the passive translator is set and there is no active
translator, then an active translator is started using the
passive translator setting.  The active translator is started
by the file system, not the program instance that set the
passive translator.  The passive translator settings are
therefore resolved in the file system's naming context, which
may be different from that of the program instance that set the
passive translator setting.

[[!tag open_issue_hurd open_issue_documentation]] <!-- Move the description of
the specific problem / example elsewhere.  -->