On Jul 20, 2007, at 09:19, Jeremias Maerki wrote:
<snip />
This means we currently end up in the strange situation where
different/separate CommonHyphenation instances are generated from
identical sets of base Property instances.
Raises the question for me if for properties without dynamic
context-based
evaluation the property evaluation could be streamlined to directly
return the primitive values instead of simple container objects like
NumberProperty. throw new NotEnoughTimeRightNowException();
The 'evaluation' here is precisely triggered by the calls to
PropertyList.get().
Before those calls in the CommonHyphenation constructor, the base
properties might not even exist yet (if they were not specified on
the FO that is bound to the CommonHyphenation).
Trading the NumberProperty for an int... No idea if that's feasible
without a thorough revision. The entire property resolution mechanism
currently depends on the generic Property return type. That design
would obviously have to be abandoned for this handful of cases...
<snip />
public boolean hyphenate() {
return (hyphenate.getEnum() == EN_TRUE);
Well, I'd prefer Bean-style getters, i.e. getLanguage(),
isHyphenationEnabled()
No problem. That was only by means of an example.
Opinions?
For the interested parties: full CommonHyphenation below, following
roughly the same principles as the Property caching.
"hash" should probably be transient here because it's a cached value.
Checked this out, and transient seems to be only applicable in a
serialization context. If the object is never serialized, adding that
keyword would seem to have zero effect... unless I'm missing something.
Cheers
Andreas
