I like the generation process as it allowed me to try out and experiment with different optimizations. I don't think that I realisticly could have added caching of compound properties or changed the abs2rel/rel2abs code if I had to change the Maker classes manually.
[J.Pietschmann]
If its common code, that's what class hierarchies and inheritance are made for.
Indeed, but then I think you are talking about a cleaner rewritten property handling class hierarchies, right?
But in what we have generated now, the similarities isn't handled by inheritance. So there is a certain amount of repeated-but-not-equal code in the Maker classes.
For instance, the 22 makers with isCorrespondingForced() methods, generates this kind of code in HEAD:
public boolean isCorrespondingForced(PropertyList propertyList) {
FObj parentFO = propertyList.getParentFObj();
StringBuffer sbExpr=new StringBuffer();
sbExpr.setLength(0);
sbExpr.append("margin-");
sbExpr.append(propertyList.wmRelToAbs(PropertyList.START));
if (propertyList.getExplicit(sbExpr.toString()) != null)
return true;
return false;
}and my optimized code looks like this:
public boolean isCorrespondingForced(PropertyList propertyList) {
FObj parentFO = propertyList.getParentFObj();
if (propertyList.getExplicit(propertyList.wmMap(
Constants.P_MARGIN_LEFT,
Constants.P_MARGIN_RIGHT,
Constants.P_MARGIN_TOP)) != null)
return true;
return false;
}Another optimization that I would like to try out, involves creating a "copy" of the PropertyList.findProperty() method in the Maker classes, but one that doesn't call isCorrespondingForced() if the maker knows that it always return false and doesn't call getExplicit if there isn't any shorthands defined. Such an experiment is downright impossible if the Maker isn't generated.
regards, finn
