Peter B. West wrote: > Victor Mote wrote: > > Yes, yes, yes. Since we are trying to eliminate the need for unnecessary > > object creation, why create a MinOptMax object? Why not just return the > > three resolved values in separate methods. Anything that uses the > > information will have to separately address the 3 pieces of > data anyway, so > > I don't see any advantage to packaging them in an object. > > > > In fact, in alt.design, getPropertyValue(PropNames.LEADER_LENGTH_MINIMUM) > etc. > > Speaking of the minimal API, why not PropertyValue getPropertyValue(int > propertyIndex)? This is presumably defined on FONode or some such, and > FONode also presumably knows how to navigate the FO tree and related > Area tree in order to resolve percentages and the like.
That may be OK for the internal-to-FO-Tree logic, but I don't think is suitable for the API, primarily because you are locked into one signature for all properties. 1) There may be some properties for which we want to return a non-integer value (Font object, for example). 2) There may be some properties for which we wish to pass more information. 3) You are going to have some ugly case or switch logic that has to determine which property is being dealt with. My opinion is that this is not a sound approach. Victor Mote
