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:
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
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 ca
Victor Mote wrote:
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 s
--- Victor Mote <[EMAIL PROTECTED]> wrote:
> The previous posting seems to indicate that the
> properties have been
> decomposed, the chronologically latter posting seems
> to indicate that the
> shorthand retains its shorthand character.
I think Peter and I were talking about inner-to-FO
propert
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, do
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 sepa
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) def
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 shorthan
--- "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
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, fortunate
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
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, fo
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 Prop
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 commo
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 XS
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 ?
-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 files--suggests
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 commo
+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 gla
[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 com
[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 li
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
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
Thanks, Finn and John Austin, for your efforts here.
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 nec
25 matches
Mail list logo