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.
If we go towards integer representation, properties in the API will always be represented by integers. By looking at this particular signature, we are not locking ourselves in. We can add other signatures if the need arises, but they can be extensions of the basic call.
The above call does not return an int or an Integer, but a PropertyValue.
public PropertyValue getPropertyValue(int property)
is, in fact, the signature from FONode.java in alt.design.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
