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.

Disadvantages -

The file becomes extremely cumbersome. This can cause problems with "intelligent" editors. E.g. XEmacs syntax highlighting virtually grinds to a halt with the current version of this file.

Possible problems with IDEs. There may be speed problems or even overflow problems with various IDEs. The current version of this and related files had only been tried with the [X]Emacs JDE environment, without difficulties apart from the editor speed problems mentioned above.

Retro look and feel. Not the done Java thing.

Advantages -

Everything to do with properties in the one place (more or less.)

Eliminates the need for a large part of the (sometimes) necessary evil of code generation. The One Big File of 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:

PropNames -

Contains an array, 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.)

PropertyConsts -

Contains two basic sets of data:
Property-indexed arrays and property set definitions.

Property-indexed arrays are elaborations of the property indexing idea discussed in relation to the arrays of property stacks. One of the arrays is

public static final LinkedList[] propertyStacks

This is an array of stacks, implemented as LinkedLists, one for each property.

The other arrays provide indexed access to fields which are, in most cases, common to all of the properties. An exception is

public static final Method[] complexMethods

which contains a reference to the method 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.

The property-indexed arrays are initialized by 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.

Property set definitions are HashSets 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 HashSets include backgroundProps and tableProps.

Properties -

This class contains only sets of constants for use by the individual property classes, but it also importantly serves as a container for all of the property classes, and some convenience pseudo-property classes.

Constants sets include:

Datatype constants. A bitmap set of integer constants over a possible range of 2^0 to 2^31 (represented as -2147483648). E.g.
INTEGER = 1
ENUM = 524288

Some of the definitions are bit-ORed combinations of the basic values. Used to set the dataTypes field of the property classes.

Trait mapping constants. A bitmap set of integer constants over a possible range of 2^0 to 2^31 (represented as -2147483648), representing the manner in which a property maps into a trait. Used to set the traitMapping field of the property classes.

Initial value constants. A sequence of integer constants representing the datatype of the initial value of a property. Used to set the initialValueType field of the property classes.

Inheritance value constants. A sequence of integer constants representing the way in which the property is normally inherited. Used to set the inherited field of the property classes.

Nested property classes. The Properties class serves as the holding pen for all of the individual property classes, and for property pseudo-classes which contain data common to a number of actual properties, e.g. ColorCommon.