On Jun 7, 2006, at 09:42, Jeremias Maerki wrote:
It would be interesting to know how much time is effectively lost
if the
properties are re-evaluated unconditionally.
As I indicated, it may not be much. The properties package already
contains a lot of optimizations, and I guess it depends a bit on what
is Rule and Exception here. In the current state, a property not
being re-evaluated is the exception to the rule. I'll have to browse
a bit through the Rec to see whether this reflects the prescriptions...
However, I agree with you
that it is certainly possible to skip reevaluation for many
properties.
And if it's easily possible it should be done. The "cloned"
indicator on
the FO sounds like a pretty simple and suitable solution.
Or are there better ones?
I've considered a few, but I think the suggested approach has the
benefit that it allows to settle these matters gradually. I can add
the switch now, flip it in FObj.clone(), and use it in TableCell.bind
(). Other FOs / Properties can be altered to use it at a later time,
or never for that matter.
I've also considered pulling the check to the properties' side --as
in: FObj.bind() keeps making unconditional calls to PropertyList.get
(), and the latter sorts out whether the FO was cloned.
That would expose the 'cloned' switch one way or the other --adding
yet another public accessor is probably the easiest way to go about
that, but I somehow don't like this (unless that access would, for
example, come in handy for the layoutengine or other packages)
Andreas
