Re: Unnesting properties and makers.

Finn Bock Fri, 23 Jan 2004 08:02:20 -0800

Does anyone know why we wrap the datatypes instances in a property instance? I think we could avoid the property instance by having the datatypes extends an AbstractProperty class which implement a Property interface:

[Glen Mazza]

Could you explain why we have the datatypes instances
to begin with--what they're for?  I'm not sure what
their precise purpose is.

The datatypes are the slightly more complex property values. The property classes wraps the datatype in order to give the datatypes a common interface.

This list show the concrete Property subclasses and the datatypes that each of them wraps.

CharacterProperty        char
ColorTypeProperty        ColorType (*)
CondLengthProperty       CondLength (*)
EnumProperty             int
KeepProperty             Keep (*)
LengthPairProperty       LengthPair (*)
LengthProperty           Length,AutoLength,FixedLength,PercentLength (*)
LengthRangeProperty      LengthRange (*)
ListProperty             Vector
NCNameProperty           String
NumberProperty           Number
NumericProperty          Numeric (*)
SpaceProperty            Space
StringProperty           String
ToBeImplementedProperty

Some of the concrete property subclasses wraps standard java types such as int, char, String, Number and Vector and for these properties we still need a wrapper. But some of them, marked with (*), wraps a datatype which is under our own control and for those properties, the datatype class could also function as the property wrapper.

Offhand, it's doesn't seem natural to go without Property objects--they are kept in the PropertyList and indexed by the property ID in that list.

That would still be the case. Everything stored in the PropertyList implements the Property interface. In the list below of the new property classes, all the <type>Type classes implements Property and are stored in PropertyList.

CharacterType           char
ColorTypeType           it-self
CondLengthType          it-self
EnumType                int
KeepType                it-self
LengthPairType          it-self
LengthType, AutoLengthType, FixedLengthType, PercentLengthType
                        it-self
LengthRangeType         it-self
ListType                Vector
NCNameType              String
NumberType              Number
NumericType             it-self
SpaceType               it-self
StringType              String
ToBeImplementedType

Each of the <type>Type classes also implements the get<type> methods from Property so the layout must do exactly the same as it does now to extract the right value:

   propertyList.get(PR_INLINE_PROGRESSION_DIMENSION).
                 getLengthRange().getOptimum().getLength();

For the classes which are both property and datatype, the get<type> method becomes:

    public <type> get<type>() {
        this this;
    }

Furthermore, those are the objects requested by
layout.  What would be your alternative storage
technique otherwise--I believe, we do (frequently?)
have more than one datatype per property, correct?

I remember two cases, but I can only find one at the moment: In Title.setup():

        prop = this.propertyList.get(PR_BASELINE_SHIFT);
        if (prop instanceof LengthProperty) {
            Length bShift = prop.getLength();
        } else if (prop instanceof EnumProperty) {
            int bShift = prop.getEnum();
        }

This would stay the same, except LengthProperty would be called LengthType and EnumProperty would be called EnumType. Except that the code above should IMHO use "if (prop.getLength() != null)" to test for a length type instead of using instanceof.

I'm not sure what I propose as the naming convention for the new combined property/value, but Alt-Design calls them <type>Type so I used that in the list above.

regards,
finn

Re: Unnesting properties and makers.

Reply via email to