[Glen Mazza]

I now understand what you're saying, and like the
simplification you're suggesting. The current naming
however, is probably preferable--the word "Property" figures quite highly in the spec! Do you have a
problem remaining with it?

Not at all, it is just that I though it would be confusing to rename the 'datatypes' classes to XXXProperty as they would conflict with the old XXXProperty classes, but it is only a problem when you compare before vs. after. If the change is done, the resulting XXXProperty classes will be completely consistent.

For those (*)'ed datatypes, can't we get rid of the
datatype instead by rolling that datatype into the
equivalently named Property? In turn, have *those*
Properties extend AbstractProperty as you suggest. Actually, I guess I'm just saying the same thing
you're suggesting, except to use "--Property" instead
of "--Type" for everything.

Indeed. Which package should the resulting rolled datatype/property be placed in? My feeling says fop.datatypes (and the nested makers should be unnested and placed in fop.fo.properties). But that is a separate suggestion which does not have to be dealt with initially.

Offhand, it's doesn't seem natural to go without
Property objects--they are kept in the


and indexed by the property ID in that list.

That would still be the case. Everything stored in
the PropertyList implements the Property interface.

But only a few of them would extend AbstractProperty,
correct--or would you plan on having all do so?

All of the properties would extend AbstractProperty. That way the properties get the default 'null' implementation of all the get<type> methods. The only hard requirement is that all the properties implement the Property interface.

Except that the
code above should IMHO use "if (prop.getLength() !=
null)" to test for a length type instead of using instanceof.

Well, instanceof is slower I believe, but better self-commenting. If you switch to this type of conditional for speed, just add a short comment of its purpose--here, to determine if we are working with an EnumProperty or a LengthProperty.

(Another option, BTW, if you think it will cut down on
buggy programming, is to have the classes implementing
this Property interface supply unsupported interface
methods a la Peter's Read-Only BitSet[1], i.e., throw
exceptions.  We can revisit this topic later if code
errors are becoming a problem.)

In most cases a NPE exception is throws immediately after the call to get<type>, but an exception thrown from within the get<type> could indeed carry more information about the cause of failure. I still like the null return and null test better than the alternatives tho.


Reply via email to