Question

I’m doing a bit of playing about to learn a framework I’m contributing to, and an interesting question came up. EDIT: I’m doing some basic filters in the Okapi Framework, as described in this guide, note that the filter must return different event types to be useful, and that resources must be used by reference (as the same resource may be used in other filters later). Here’s the code I’m working with:

    while (filter.hasNext()) {
        Event event = filter.next();
        if (event.isTextUnit()) {
            TextUnit tu = (TextUnit)event.getResource();
            if (tu.isTranslatable()) {
                //do something with it
            }
        }
    }

Note the cast of the resource to a TextUnit object on line 4. This works, I know it’s a TextUnit because events that are isTextUnit() will always have a TextUnit resource. However, an alternative would be to add an asTextUnit() method to the IResource interface that returns the event as a TextUnit (as well as equivalent methods for each common resource type), so that the line would become:

            TextUnit tu = event.getResource().asTextUnit;

Another approach might be providing a static casting method in TextUnit itself, along the lines of:

            TextUnit tu = TextUnit.fromResource(event.getResource());

My question is: what are some arguments for doing it one way or the other? Are there performance differences?

The main advantage I can think of with asTextUnit() (or .fromResource) is that more appropriate exceptions could be thrown if someone tries to get a resource as the wrong type (i.e. with a message like "Cannot get this RawDocument type resource as a TextUnit - use asRawDocument()" or "The resource is not a TextUnit").

The main disadvantages I can think of with .asTextUnit() is that each resource type would then have to implement all the methods (most of which will just throw an exception), and if another major resource type is added there would be some refactoring to add the new method to every resource type (although there’s no reason the .asSomething() methods would have to be defined for every possible type, the less common resources could just be cast, although this would lead to inconsistency of approach). This wouldn’t be a problem with .fromResource() since it’s just one method per type, and could be added or not per type depending on preference.

Answer 1

If the aim is to test an object’s type and cast it, then I don’t see any value in creating / using custom isXyz and asXyz methods. You just end up with a bunch of extra methods that make little difference to code readability.

Re: your point about appropriate exception messages, I would say that it is most likely not worth it. It is reasonable to assume that not having a TextUnit when a TextUnit is expected is symptom of a bug somewhere. IMO, it is not worthwhile trying to provide “user friendly” diagnostics for bugs. The person that the information is aimed at is a Java programmer, and for that person the default message and stacktrace for a regular ClassCastException (and the source code) provides all of the information required. (Translating it into pretty language adds no real value.)

On the flip-side, the performance differences between the two forms are not likely to be significant. But consider this:

    if (x instanceof Y) {
        ((Y) x).someYMethod();
    }

versus

    if (x.isY()) {
        x.asY().someYMethod();
    }

    boolean isY(X x) { return x instanceof Y; }
    Y asY(X x) { return (Y) x; }

The optimizer might be able to do a better job of the first compared with the second.

• It might not inline the method calls in the second case, especially if it is changed to use instanceof and throw a custom exception.

• It is less likely to figure out that only one type test is really required in the second case. (It might not in the first case either … but it is more likely to.)

But either way, the performance difference is going to be small.

---

Summary, the fancy methods are not really worth the effort, though they don’t do any real harm.

---

Now if the isXyz or asXyz methods were testing the state of the object (not just the object’s Java type), or if the asXyz was returning a wrapper, then the answers would be different …