Peter B. West wrote:
Victor Mote wrote:
Yes, yes, yes. Since we are trying to eliminate the need for unnecessary
object creation, why create a MinOptMax object? Why not just return the
three resolved values in separate methods. Anything that uses the
information will have to separately
Peter B. West wrote:
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve
Peter B. West wrote:
If we go towards integer representation, properties in the API will
always be represented by integers. By looking at this particular
signature, we are not locking ourselves in. We can add other signatures
if the need arises, but they can be extensions of the basic call.
Victor Mote wrote:
Peter B. West wrote:
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already
Victor Mote wrote:
Peter B. West wrote:
If we go towards integer representation, properties in the API will
always be represented by integers. By looking at this particular
signature, we are not locking ourselves in. We can add other signatures
if the need arises, but they can be extensions of
Victor Mote wrote:
Peter B. West wrote:
It would be really nice to have a getLeaderLength()
which returns a MinOptMax. this means the getLeaderLength()
has:
- resolve percentages and functions
- deal with the leader-length shorthand setting before this
- deal with inheritance (n/a here,
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve the cases where
*both* a shorthand and one of
Glen Mazza wrote:
--- Peter B. West [EMAIL PROTECTED] wrote:
See above. In alt.design, all compounds are
shorthands, and all
shorthands are presumed to have been resolved into
their components
during FO Tree building.
BTW, does Alt-Design already resolve the cases where
*both* a shorthand
Good thing I asked--I may need to do that with the
Constants interface, where the ordering is currently
alphabetical.
Glen
--- Peter B. West [EMAIL PROTECTED] wrote:
It's in the ordering of the properties. There is a
simply for loop to
process properties (attributes, in fact) defined on
[Glen Mazza]
Thanks, Finn and John Austin, for your efforts here.
It's a pleasure.
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and
[J.Pietschmann]
[snip]
If we are at it, I'd vote for dumping generating the property
classes and check the java files into CVS.
I like the generation process as it allowed me to try out and experiment
with different optimizations. I don't think that I realisticly could
have added caching of
+1 to that, but please don't dump the original XML files
(foproperties.xml etc.) because they could come handy later.
Besides that, I can't contribute much to this discussion, but I am
confident that you guys find a good solution. The integer idea sounds
reasonable to me and I'm particularly glad
Finn Bock wrote:
I like the generation process as it allowed me to try out and experiment
with different optimizations. I don't think that I realisticly could
have added caching of compound properties or changed the abs2rel/rel2abs
code if I had to change the Maker classes manually.
If its
-1. I'd like to hold off on this, at least until I
can gain a better understanding of the autogenerated
code. I may still to the same conclusion as the other
committers, but Finn's endorsement of the XSLT--as
well as the long work of those like Keiron who have
worked with the XSLT
I haven't looked at the XSLT code but I have a question
in my mind that I need to answer about it.
I wonder what it is that is being generated and what were
the design alternatives to the codegen implementation.
One question that popped in to my head was:
Is there 'missing polymorphism' here ?
Glen Mazza wrote:
-1. I'd like to hold off on this, at least until I
can gain a better understanding of the autogenerated
code. I may still to the same conclusion as the other
committers, but Finn's endorsement of the XSLT--as
well as the long work of those like Keiron who have
worked with the
I like the generation process as it allowed me to try out and
experiment with different optimizations. I don't think that I
realisticly could have added caching of compound properties or changed
the abs2rel/rel2abs code if I had to change the Maker classes manually.
[J.Pietschmann]
If its
Glen Mazza wrote:
Thanks, Finn and John Austin, for your efforts here.
Yes, and Peter, too.
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's
Peter B. West wrote:
It would be really nice to have a getLeaderLength()
which returns a MinOptMax. this means the getLeaderLength()
has:
- resolve percentages and functions
- deal with the leader-length shorthand setting before this
- deal with inheritance (n/a here, fortunately)
J.Pietschmann wrote:
If we are at it, I'd vote for dumping generating the property
classes and check the java files into CVS.
+1. I have noted Finn's and Glen's subsequent objections, and Joerg's
subsequent comments. I agree that the general need for that level of
flexibility has passed, and
Glen Mazza wrote:
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and liked what I saw. It doesn't necessarily have to
be that particular
J.Pietschmann wrote:
Glen Mazza wrote:
Victor, not to rush you, but how agreeable are you in
general on switching to integer enumerations for FOP
properties? (Given Alt-Design, Peter obviously
approves.) I checked Alt-Design's PropNames.java[1]
and liked what I saw. It doesn't necessarily have
22 matches
Mail list logo
