Jeremias Maerki wrote:
> On 17.03.2008 20:29:07 Vincent Hennebert wrote:
>>> Author: jeremias
>>> Date: Fri Mar 14 07:41:03 2008
>>> New Revision: 637119
<snip/>
>>>              if (returnedList != null
>>>                      && returnedList.size() == 1
>>>                      && ((ListElement) 
>>> returnedList.getFirst()).isForcedBreak()) {
>>> -                // a descendant of this block has break-before
>>> -                contentList.addAll(returnedList);
>>>  
>>>                  if (curLM.isFinished() && !hasNextChildLM()) {
>>> +                    // a descendant of this block has break-before
>>> +                    contentList.addAll(returnedList);
>>> +
>>>                      forcedBreakAfterLast = 
>>> (BreakElement)contentList.removeLast();
>>>                      context.clearPendingMarks();
>>>                      break;
>>>                  }
>> What’s the point in adding a one-element list to another one if this 
>> element is removed just after that? What have I missed?
> 
> No particular point. It was refactoring to conserve existing
> functionality without looking at the bigger context. The if statement
> could probably be rewritten like this to "optimize" it.
> 
>                 if (curLM.isFinished() && !hasNextChildLM()) {
>                     // a descendant of this block has break-before
>                     forcedBreakAfterLast = 
> (BreakElement)contentList.removeLast();
>                     assert contentList.size() == 0;
>                     context.clearPendingMarks();
>                     break;
>                 }

Again, what was the additional cost of applying such a change? Isn’t the 
code of this method already complex enough?


Vincent


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Reply via email to