On 23 May 2015, at 23:15, Andreas Delmelle andreas.delme...@telenet.be
wrote:
snip /
FYI - High and medium priority warnings addressed in r1681384, and absent an
answer to my question, assumed the lazy approach there, for now.
Will try to have a look at the low priority ones tomorrow.
... and low priority warnings now addressed in r1681435.
Going through those, the number of implicit assertions made at various places
in the codebase is quite amazing.
In some cases, making those explicit looks a bit silly, but it actually makes
perfect sense.
Example from the o.a.f.render.afp package:
---
/** {@inheritDoc} */
@Override
protected AFPDataObjectInfo createDataObjectInfo() {
return new AFPGraphicsObjectInfo();
}
/** {@inheritDoc} */
public void handleImage(RenderingContext context, Image image, Rectangle pos)
throws IOException {
AFPRenderingContext afpContext = (AFPRenderingContext)context;
AFPDataObjectInfo info = createDataObjectInfo();
assert (info instanceof AFPGraphicsObjectInfo);
AFPGraphicsObjectInfo graphicsObjectInfo = (AFPGraphicsObjectInfo) info;
---
For us, humans, it looks evident that casting the object returned by
createDataObjectInfo() to an AFPGraphicsObjectInfo is legitimate.
However, strictly speaking, one cannot exclude the possibility that someone
creates a subclass and overrides createDataObjectInfo(), but not
handleImage(), in which case the code would fail at runtime with an ugly
ClassCastException...
Perhaps it is also possible and cleaner to force the return type to an
AFPGraphicsObjectInfo, which is a subclass of AFPDataObjectInfo. I may look
into that later. At least now, the assertion is clearly visible in the code.
KR
Andreas
