xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 50725] KnuthSequence documentation?
Date Mon, 07 Feb 2011 19:02:55 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=50725

--- Comment #3 from Andreas L. Delmelle <adelmelle@apache.org> 2011-02-07 14:02:52 EST
---
(In reply to comment #2)

> At the time I did this, there were no generics yet. I have long been aware 
> that this violates type safety, but I do not know a solution. 
> LM.getNextKnuthElements is called for block and inline-level LMs alike, 
> but the structure of their subtrees is different.

Right, I remember now. Well, it's not too dramatic, and the issue of type
safety mainly concerns fo:wrappers, IIC[*]. For the remainder, no biggie.
Nobody would dream of adding, say, a LayoutManager to the returnList in
getNextKnuthElements(), simply because it is obvious from the context what type
of elements is expected. It's just a nice-to-have, if we would be able to
define it in the interface. 

As for a solution, my proposal might just work fine. Given that, after the
patch, KnuthSequence is no longer a subclass of ArrayList, it is free to become
a special kind of ListElement (compound, rather than atomic). The only thing I
still have to figure out, is whether that could be useful for other purposes,
or whether that just adds more complexity and potential confusion...

[*] cfr. the ClassCastException issue that popped up a number of times in the
past, and once fixed, it resurfaced further downstream (see also Bugzilla
47530). Fixed in FlowLM, then surfaced in BlockStackingLM, then triggered by a
call to ElementListUtils...

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Mime
View raw message