More on properties

["Peter B. West" <pb...@powerup.com.au>]

I have been thinking about specifying as many of the characteristics of 
properties as possible in static data structures, one way or another. 
One approach is to create, in a non-instantiable class, static final 
arrays containing various data about properties, such as those which are 
contained in Appendix C of the spec.  These arrays are indexed by a set 
of static final ints encoding the set of properties.  These ints are 
derived from a HashMap indexed by the name of the property, and that 
HashMap is the only place in which the property name is used.  It's all 
very C.

Parallel to this class was another which had a couple of accessors and a 
set of member classes corresponding to most of the properties.  In these 
classes, themselves not originally intended for instantiation, were 
arrays of enum values for those properties whose legal values included 
one of a set of enumerated values.  As well as the String array 
containing the value as a String, there is a set of static final ints 
which encode the enumerated values.  That was the motivation for this 
set of classes; to be able to specify such property-specific constants.

This classname is accessed from another array indexed by the property 
integer constant.  I had assumed that, given the name of a class, I 
would be able to get the same access to that class, its fields, arrays 
and methods, through a variable containing the name, as I would by 
naming the class directly in my code.  That's what reflection is all 
about, right?  But I am puzzled as to how to access array elements when 
I don't actually have an array object, just the array class object. 
Arrays seem to be neither fish nor fowl in this scheme.  Can anyone 
point me in the right direction.  I would also like to hear what 
pitfalls there are in accessing class members rather than instance 
members, by such means.

My other requirement for arrays was in connection with property 
specification stacks.  One way to approach the property context for a 
given FO is to use stacks to contain the currently relevant property 
value.  I envisaged a set of stacks, one per property, initialized to 
the initial value of the property. Then, whenever a property is 
specified on an FO element, that value can be pushed onto the stack. 
(whether separate specified, computed and actual values need be stacked 
I don't know.)  At the same time, the FO node gets a list of the 
propeties which have had values pushed.

On the way out, these values are popped.  Values which are inherited, or 
on which "inherit" is specified, require no modification to the stack; 
non-inherited values for which no "inherit" is specified require that 
the initial value (available at the bottom of the stack) is pushed and 
noted.  Obviously, these stacks only attain the depth of the FO tree, so 
they are not particularly demanding of memory.  There are currently 247 
FO properties, not including compound expansions.

I thought that I would be good, and think inside the object here, 
putting the individual stacks inside each of the property classes 
mentioned above.  But the difficuties in thinking out the stack access 
are making me lean towards a separate array of stack objects.

All of the above may be of more relevance to the C/C++ project.

Any comments?

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org