On 07.07.2008 18:52:55 Andreas Delmelle wrote: > On Jul 7, 2008, at 18:09, Andreas Delmelle wrote: > > > On Jul 7, 2008, at 15:22, Jeremias Maerki wrote: > > > >> I know I'm late on this one but I've only just stumbled over it while > >> playing with the AFP renderer in the GOCA branch. This change is very > >> dangerous as it essentially breaks every FOP extension that uses > >> character content, especially those not developed inside the FOP > >> project. > >> I'm lucky it doesn't (shouldn't) break Barcode4J but I would strongly > >> suggest to revert this interface change especially since the method > >> signature doesn't change while the semantics do. > > > > I'd rather keep it the other way around, like it is now. It's much > > less confusing if the same parameters are used as in the SAX > > characters() event. > > > > If this breaks external code, then my apologies (it even broke some > > internal classes too, but those issues didn't show when running the > > test-suite; Max discovered them). > > > > Still -1 for reverting. > > Note: I do appreciate the feedback, and I see where this can become > problematic, but OTOH, if there is a class that relies on the ending > index being passed, the solution is rather straightforward. > > The change was ultimately also motivated by the simple question: > "Why did we need to compute the end-index off start and length for > every characters() event?" > The answer: "Because FONode.addCharacters() expected it." That's the > only reason, so it made more sense to simply make it a length (no > additional operation needed) and only compute the end index if we > really need it... > > That said: Would it relieve your concerns a bit if this change were > better documented?
No, breaking backwards compatibility remains a break. Authors of extensions have to branch off new versions of their plug-ins. How many times did we get annoyed when Batik changed their bridge APIs in a non-backwards-compatible way? Even I had to restore backwards compatibility in the renderers after some of my own changes because they would have broken Barcode4J and I would have had to branch off a new variant of the extension which easily leads to a support nightmare: which extension do I need for which FOP version? Am I the only one concerned about backwards-compatibility here? > (Which I'd be glad to take care of, since I > neglected to do so in spite of the change being so high up in the > hierarchy /and/ exposed to potential subclasses... :/) > > > Andreas Jeremias Maerki
