Oberon || Library || Module Index || Search Engine || Definition || Module

Ulm's Oberon Library:
TranslucentNames

NAME

SYNOPSIS

CONST mergesort = 0;
CONST unsorted = 1;
TYPE DirMode = SHORTINT; (* mergesort or unsorted *)



PROCEDURE Create(VAR node: Names.Node;
                 readonly, writable: Names.Node;
                 rauth, wauth: Shards.Lid;
                 status: Names.Status;
                 dirmode: DirMode);



PROCEDURE CreateFactory(VAR factory: NodeFactories.Factory;
                        readonly, writable: ARRAY OF CHAR;
                        rauth, wauth: Shards.Lid;
                        status: Names.Status;
                        dirmode: DirMode);

DESCRIPTION

• all nodes of the second hierarchy are to be seen,
• all nodes of the first hierarchy can be seen as long as they are not in conflict to those of the second hierarchy, and
• all modifying Names operations on nodes with the domain capability are effective in the second hierarchy only. (If this requires the creation of paths that were so far visible in the first hierarchy only, they are recreated in the second hierarchy).

In other words: We are operating on the second hierarchy but the first hierarchy is seen through the second hierarchy as long it is not covered by existing entries of the second hierarchy.

Whenever a node of the translucent system is asked for a list of members (Names.GetMembers) a list of names is returned which consists of entries of the second hierarchy and, as long as their names are not present in the second hierarchy, of entries of the first hierarchy. The order in which these names are presented depends on the selected dirmode:

mergesort

Assume that both hierarchies return alphabetically sorted member lists. Then this directory mode causes the translucent hierarchy to return sorted member lists as well. Note, however, that if this assumption does not hold, the same name can be returned twice in a member listing.

unsorted

Do not assume the hierarchies to be sorted and do not generate a sorted member list either. Instead, the members of the second hierarchy are returned in their original order, followed by the members of the first hierarchy whose names are not present in the second hierarchy, again in their original order.

TranslucentNames supports the proxy framework of Proxies and uses the directory nodes of the second hierarchy as heirs for the creation of translucent directory nodes. This means that if a directory node of the second hierarchy is of an extended type of Names.Node that is supported by Proxies, the corresponding node of the translucent hierarchy will be of this extended type as well.

Create returns a newly created translucent hierarchy in node that combines readonly (as first hierarchy) with writable (as second hierarchy). On all operations delegated to readonly, rauth will be passed on as authorization. Likewise wauth will be passed to all operations forwarded to writable. The access to directory nodes of the translucent system itself must be authorized according to the status parameter. The directory mode dirmode determines how member listings are composed out of the listings from the two underlying hierarchies (see above).

CreateFactory takes the parameters as Create and returns a newly created factory that generates translucent hierarchies as specified by these parameters.

DIAGNOSTICS

SEE ALSO

Names

general abstraction for name hierarchies

Proxies

framework for proxy objects

Oberon || Library || Module Index || Search Engine || Definition || Module