Towards a Methodology for Variant Allocation of Slot Values in Common Lisp Implementations of IDL Interfaces — Following a Review of a Singular IDL Interface Definition in the Document Object Model (DOM) Level 2 Style Specification

In reviewing the DOM Level 2 Style Specification[1] towards possible development of a CORBA document system, moreover considering the specification for possible implementation of object client services in a Common Lisp programming system, furthermore in reviewing — broadly — the manner in which the IDL  interface definitions, as comprising IDL features, are defined in any single specification, immediately the Interface definition for CSS2Properties[2] catches the author's own sense of attention as with regards to how many attributes the corresponding interface definition[2] specifies, in albeit. a broad estimation of how many atributes will be uniquely bound to a value, across any discrete number of objects implementing the respective interface definition in any single application of the specification.

Rather than to presume as though to redefine the specification itself, it may be possible to develop a relatively less memory-intensive implementation in Common Lisp. Hypothetically, if each such attribute definition was to be accompanied with a Common Lisp slot definition — referring to the Common Lisp Object System (CLOS) and extensiinally, the Metaobject Protocol (MOP) — and each slot definition accompanied with a per-instance slot allocation, but not allocated until a value would be uniquely stored to the respective attribute or its implementing slot, each slot being allocatee individually in each object to which the interface definition would serve to provide object services, then it may result in a substantial savings in application data storage area, contrasted to a by-in-large redundant property value storage as would be created of conventional instance slot allocation in an immediately portable Common Lisp implementation of the same interface definition.

Hypothetically, each such slot definition, in CLOS, may be defined portably as a class allocated slot definition — presumaby, each class allocated slot then initialized in its class allocated slot value, at a discrete time, corresponding with each slot definition's initform. Instances of the class itself may be specifically intialized, each with two adjustable arrays — an adjustable offsets vector of an element type sufficient to store an index value of each slot definition, and an adjustable values vector of element type T, serving as a buffer for slot values of attribute slots in the respective instance. To set a slot's value for an attribute slot not previously boundp, the offsets vector and the values vector would each have a value appended, respectively of the offsets vector index for the slot definition, and the slot value for the slot as denoted by the offset vector index.

The respective offsets vector and values vector would each store a value only for each allocated slot — plus any padding up to a value A, for A representing the maximum of the difference between the actual array dimension and the array displacement offset. For instances such as of a class implementing the IDL interface, CSS2Properties[2], in which it may be expected that only a small number of slot values would differ from any application default in each instance, the  offset/values vector implementation may result in a smaller net memory allocation, albeit with an effective tradeoff in the form of a slightly greater slot value access time — each slot value read operation requiring a check of the slot's offest vector index, then a check for the boundp status via a scan of the offets vector, previous to either a slot-unbound error (if not simply to return two values nil, nil, allowing for any application-local defaulting to be dispatched on the second rerurn value) or an access to the respective position in the instance's values vector, to retrieve the slot's value at that offset (returning that value as the first return value of the slot-value method and a second value, a positive intiger, that value indicating both that the slot is boundp, therefore need not be processed for any manner of application-local default value, ane indicating the slot value's offset in the slot values vector.)

A slot value write operation should be preceded by a similar scanning operation, subsequent to either replacing the slot's value at an existing position in the values vector, or extending both of the boundp vector and the values vector to acommodate a new slot-value binding (A second value may be rerurned, in either outcome, as to indicate the slot values vector offset of the newly established slot value.)

For purpose of thread safety, each such attribute allocated slots instance may be initialized with a mutex object defined as to serve as a modal read/write lock onto both of the offsets vector and the values vector of the respective instance. For the duration of each combined slot value writing procedure, the modal lock would be allocated in an exclusive write mode, or allocated in shared read mode, as for the duration of each successive individual or batch-wise slot value reading procedure.

During object initialization — such as of a CLOS method specialized onto shared-initialize — the modal attribute slot values lock for the interface implementor instance may be created,  acquired in exclusive write mode,and stored in the respective instsnce slot,  previous to storage of the full set of slot values provided to the initialization method instance — leaving the values of other slot definitions to be computed by means of application-specific default value computation, such as viz a viz the cadcading model in cascading stylesheets.

In order to minimize any ambiguity as might occur about the meanings and storage of slot values, in this specialized extension of CLOS and MOP for such implementation of IDL Interface attributes, a set of functions and macros may be defined such that would present access only to the set of attribute slot definitions — analogous to class-slots, slot-boundp, slot-value, and (setf slot-value), with-slots, etc. This, in turn, may be integrated with any broader protocols for CORBA Interface reflection, at the application layer.

This approach may be somewhat computationally more expensive, in such a methodology — such as would allow for a variant allocation of non-default slot values. For an application initializing many of an instance of CSS2Properties[2], for example, it may overall serve to minimize utilization of application data storage space, in a positive tradeoff for the slighly more complex slot value access procedures.

Insofar as this approach may serve to extendof any analogies onto applications of the original design of portable CLOS and MOP specifications,  such uniquely setf allocated slot definitions would be neither singularly class allocated nor expressly instance allocated in any MOP-conventional manner, in each respective slot definition.

Concerning inheritance of slot definitions' properties across any single superclass/subclass relation, each such setf allocated slot definition A, defined in a class M, would likewise be defined as a setf allocated slot definition A, in a subclass N of M.

It is not expected that this protocol may serve to overly complicate other extensional slot definition protocols, except of any relying expressly on portable allocation qualifiers for slot definitions.

Prospectively, the methodology for unique instance-local slot value allocation — as described in this document — may be furthermore extended as to develop an emulation of the schema/prototype and formula-values  object models as originally developed in Garnet KR, prospectively as may be emulated onto CLOS and MOP via any methodology perhaps similarly extending of portable CLOS/MOP slot allocation specifiers.

[1] http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/Overview.html
[2] http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.html#CSS-CSS2Properties