Hi, the class MinOptMax has some 800 usages in FOP. It holds a triple of values (min, opt, max) of length quantities.
It's heavily used during local computations and passing around. It's fields are public (whereas the class comment says they are only package visible). The public fields (and many methods) make MinOptMax mutable. This mutability is used in the computations for sheer performance reasons. But this mutability is a big bug attractor in passing around situations. I don't think that anyone would wonder that an immutable MinOptMax would help FOP. This refactoring wouldn't be rocket science if all usages of MinOptMax would be covered by tests. I just started and found many such uncovered sections. I'm very new here and so I simply can't write such tests. So I ask you to possible write such tests or remove uncovered code sections. As for performance. I would opt for just refactoring all stuff to immutable MinOptMax and only introduce an MinOptMaxBuffer if really needed. With an immutable MinOptMax we can easily remove all TODO's inside MinOptMax. The integrity tests (min <= opt <= max) and we can remove the clone method, because it wouldn't be needed anymore. I just started the refactoring. All what I need are unit tests. Best Regards Alex -- e-mail: [email protected] web: www.alexanderkiel.net
signature.asc
Description: This is a digitally signed message part
