Hash::Layered

Perl module for hash access with stack like state

Overview

The Data::LayeredHash module provides a structure which acts as a normal hash (via tie), but where the hash data and structure are spread over multiple layers. Layers are managed like a stack and may selectively or completely obscure layers deeper in the stack, dynamically changing the value and even existance of hash data.

• Layer Methods
• push(): create a new layer and place it on top of the layer stack. Returns the ID of the new layer.
• pop(): remove the top layer from the layer stack. Returns the ID of the popped layer (which is no longer valid).
• set_default('SEMANTIC'): set the default layer semantics. Returns previous setting.
• set_layer('SEMANTIC' [,'ID']): set the current [or specified] layer's semantics. Returns previous setting
• set_default_SEMANTIC(): shorthand for set_default('SEMANTIC')
• set_SEMANTIC(): shorthand for set_layer('SEMANTIC')
• id(): returns the ID for current layer

• Layer Access Semantics Definitions (functional term / glass analogy term)
• obstruct/opaque: the layer completely hides higher layers
• flat/transparent: the layer is ignored unless a key already exists in it: "this layer is flat, no space for new things"
• hidden/invisible: the layer is ignored (when not the current layer)
• protect/oneway: the layer is opaque for writes and transparent for reads
• cascade/biased: the layer is opaque for new keys, and transparent to existing keys (existing as defined by layers)

The layer semantics affect searches for keys that are not defined in the current layer. The semantics are referred to by a functional term and a term from an analogy to each layer being a pane of glass, with keys denoting fixed areas where values are written on the glass surface. Stacking the panes in order and then looking from the current layer's pane toward's the base layer's pane. (I don't know if the analogy is useful, but I originally used the glass terms for the module, and this justifies leaving them in :)

Future: Functions to reorder the layer structure entirely. This could be useful for the sgml transform to save each mode as a layer, then reorder them when the current modes are changed. Maybe allow a layer to be placed at multiple points in the layering. Add a layer shift and unshift. [Will wait for a clear need.]

Future: Add semantic information for individual hash keys. This is not particularly necessary, as extra layers can achieve similar effects. For example: transparent, opaque, selective, first. Delete on a 'first' key would remove most recent. Delete on an 'opaque' or 'selective' key would remove it from the current layer. Delete on a 'transparent' key would remove it from all layers.