Re: More style issues
On Fri, Sep 09, 2005 at 08:38:18AM +0800, Manuel Mall wrote:
On Fri, 9 Sep 2005 07:55 am, J.Pietschmann wrote:
Hi devs,
while examining the Checkstyle and JavaDoc complaints I
got a few more questions about the FOP style:
1. There is still quite a bit of hungarian notation here and
there. Hungarian notation generally sucks unless it is
consistently applied. Furthermore, it is systems hungarian
(see http://www.joelonsoftware.com/articles/Wrong.html),
which unconditionally sucks.
And yes, we do already have an int bFooFlag.
I'd like to exterminate this.
+1 I am with you here - allthough I am guilty as well: If I find a class
written in hungarian style and I have to make a modification I will
sick with the style of the original author. What I dislike most is
mixing styles as this make code IMO very difficult to read.
Hmm, if I remember FOP code uses b and i for boolean and int, and I
have added to that usage. I do not have a problem with it. It may not
add information, but I like the fact that it carries type info with
it. It certainly does not bother me.
2. There are two different styles for constructors and setters
in use:
Constructor(int foo) {
this.foo=foo
}
and
Constructor(int f) {
foo=f
}
We should standardize on one form. I'd like the first because
the second may have the undesirable effect of using unintuitive
abbreviations or alternative names for the parameter.
I told Checkstyle laready to accept the first form (there are
*lots* of warnings about it). Unfortunately, Checkstyle can't yet
enforce it.
Doesn't worry me too much although I prefer the style you prefer as
well.
That is my position as well.
3. We have too much weird abbreviations everywhere. In particular,
usage of abbreviations is wildly inconsistent. I'd like to
remind everyone that using proper words to compose identifiers
has advantages. With the autocompletion features of modern IDEs,
long identifiers shouldn't impair typing too much.
I'll probably expand randomly choosen names in the future, which
may include class names. Tell me now if you don't like this.
That's a difficult one - I don't think there is a right or wrong here.
And yes consistency would be great (e.g. all layout manager classes
should be called ...LayoutManager and not some ...LM). I agree that
this is not really a typing issue but it is arguable at what length an
identifier actually gets in the way of readability, e.g. is
'lineStartBorderAndPaddingWidth' preferable to 'lineStartBAP' if that
variable is used a lot in expressions which are then split over multi
lines everywhere this variable is used?
What about a WIKI page listing commonly used abbreviations found in the
code base?
So +1 for consistent class names and +1 for consistent and considered
use of abbreviations but please don't ban them altogether.
I feel the same way.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Classpath setup problem
On Tue, Sep 06, 2005 at 10:48:11PM +0200, J.Pietschmann wrote: Next question: I used to have old (maintenance branch) jars for FOP and Batik in the repository, which causes compilation problems. Therefore it might be a good idea to include only specific fles rather than *.jar in the classpath set. WDYT? What do you mean with repository? xml-fop/lib? Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Space-resolution doesn't work
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only the
elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
} else {
// there can be a break between the children
createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
}
This is a good idea. Each LM would invoke this whenever it steps from
one child to another. Only the top level LM would also invoke it for
its before and after edges.
I would think of a different treatment of the spaces (space specifiers):
List spaces = new List(currentChild.getSpacesAfter(),
nextChild.getSpacesBefore());
createElementsForSpaces(spaces);
createElementsForSpaces would create a single glue and a single
penalty, because all space specifiers in a single block stacking
constraint need to be considered together to calculate the space
value. Resolution and creating elements go together, as a penalty must
be created to reflect the influence of a page break.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Tables, Columns... : FOTree or Layout?
Andreas, You are asking a lot of questions. To most I have no answer, but I have one reservation. On Sat, Sep 10, 2005 at 01:41:05AM +0200, Andreas L Delmelle wrote: The other ones I encountered so far: implicit columns (from cells in first row), column-number and number-columns-repeated. Especially the second seems out of place in layout, since it is needed by the (currently unimplemented) function from-table-column(). If the column-numbering is deferred until layout, it seems to become all the more difficult to provide an eventual implementation for this function. The other two are closely related to this, since they are necessary to get the column-numbers right. This kind of on-the-fly normalization of the tree structure has advantages for layout in that the table-grid co-ordinates will be readily available (no interpretation needed, just pick up the cells as building-blocks and map them onto the grid without too much effort). The only downside is that certain information is lost. The tree structure won't be the structure as specified in the source document, but will actually correspond to another structure that yields exactly the same results. This bothers me. It may hinder proper calculation of property value inheritance, which follows the tree as given by the user. We do property refinement on the tree; other than that it is a precise reflection of the user's fo document. I am reluctant to change that. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: FOP website, release preparations: refactoring necessary
I apologize for not responding sooner, but I've been very busy lately. Anyways, I've finally found some time to get working on the website. I think I got everything right, now I just need to work on some broken links. Also, I am wondering if the svn diff will show everything (I moved some files around, for example the ones listed below are now in a directory called 0.20.5). I hope this is not a big issue. Cheers, Patrick Paul Jeremias Maerki wrote: Ok, so let's try to come up with a list. I see: The whole Using FOP section - compiling.xml - configuration.xml - running.xml - embedding.xml - servlets.xml - anttask.xml then most of Features: - output.xml - pdfencryption.xml - graphics.xml - fonts.xml - hyphenation.xml - extensions.xml The only item left out is this last section was compliance.xml which contains information for both versions. I'm not sure what to do with it. On 29.08.2005 00:10:31 Patrick Paul wrote: Now I have to determine what goes in the 2 newly created tabs. ;-) Jeremias Maerki
