If individual properties can have a "virtual reality" on the
stack, where is the stack itself to be instantiated? One
possibility is to have the stacks as static
data structures within the individual property classes.
However, the reduction of individual property instances to
stack entries allows the possibility of further
virtualization of property classes. If the individual
properties can be represented by an integer, i.e. a
static final int
, the set of individual
property stacks can be collected together into one array.
Where to put such an overall collection? Creating an
über-class to accommodate everything that applies to
property classes as a whole allows this array to be defined
as a static final
something[].
This approach has been taken for the experimental code.
Rather than simply creating a overall class containing
common elements of properties and acting as a superclass,
advantage has been taken of the facility for nesting of
top-level classes. All of the individual property classes
are nested within the Properties
class.
This has advantages and disadvantages.
foproperties.xml
, with its ancillary xsl, is
absorbed into the One Bigger File of
Properties.java
. The huge advantage of this
is that it is Java.
In fact, in order to keep the size of the file down to more a more manageable level, the property information classes of static data and methods have been split tentatively into three:
propertyNames
, of the names of
all properties, and a set of enumeration constants, one
for each property name in the PropertyNames
array. These constants index the name of the properties
in propertyNames
, and must be manually kept in
sync with the entries in the array. (This was the last of
the classes split off from the original single class;
hence the naming tiredness.)
public static final LinkedList[]
propertyStacks
LinkedList
s, one for each property.public static final Method[]
complexMethods
complex()
which is only defined for
properties which have complex value parsing requirements.
It is likely that a similar array will be defined for
properties which allow a value of auto.static
initializers in this class. The
PropNames
class and
Properties
nested classes are scanned in order to obtain or derive
the data necessary for initialization.HashSet
s of properties (represented by
integer constants) which belong to each of the categories
of properties defined. They are used to simplify the
assignment of property sets to individual FOs.
Representative HashSet
s include
backgroundProps and
tableProps.traitMapping
field of the property
classes.initialValueType
field of the property
classes.inherited
field of the property
classes.Previous: alt.properties
Next: Properties classes