--- Finn Bock <[EMAIL PROTECTED]> wrote:
> > So if we did this at the FO level, in effect, we'd
> > have to (1) store an instance variable of every
> > property for each FO, given that we wouldn't know
> > whether the FOEventHandler's needs it beforehand,
> Yes. Which is massively more efficient than storing
> the exact same
> properties in a PropertyList.
Why is it more efficient (I know it is, given your
metrics, but want to know why)--aren't you just moving
the values already stored in the PropertyList into
separate fields in the FO objects? Yes, you're
releasing the PropertyList's memory, but the elements
that the PropertyList previously stored are now stored
in the FObj.
So if PropertyList can be thought of as a C-like
struct holding the values of its FObj's properties,
what you're doing appears to be just taking that
struct's member variables and moving them to the FObj.
But, obviously, given the performance/memory boost
you're noting, PropertyList *can't* be regarded as a
C-like struct. Why? Could PropertyList be made more
efficient instead of this change--make it more like a
> > (2) instead of the programmatic convenience of
> > getPropString(PR_OFFICIAL_PROPERTY_NAME), we'd
> have to
> > remember what each of the properties are named in
> > FO's (We can probably standardize these though.)
> I've consistly picked getOfficielPropertyName() as
> the name of the
> getter method.
OK--good--strike that argument then. (Although that's
a lot of methods for us to have.)
> > Another clarification needed: when would the
> > list's memory get released--at the PageSequence
> > or as soon as the FO is finished?
> At the endElement() event.
OK, I like that--it guarantees that every node's
ancestor--even FORoot is alive while that node is
being processed. This is good.
> > Because the values
> > of some FO's properties further downstream depend
> > an earlier FO's properties, we may not be able to
> > release the memory when the earlier FO is
> If a property value is needed by a following
> sibling, then it can be
> found as an instance field on the fo object that
> defined the property.
Yes, I see. Good.