Add more helper methods for dealing with union types

[berler]

What happened?

We have a lot of data structures that are unions with many possible value types (sometimes over a dozen). Working with these can be very difficult since code needs to implement a visitor for all possible types, even if the code wants to ignore most of those types, or in the cases of tests assert that the object has a specific type (in tests it isn't very obvious how you would even construct a Matcher for these without implementing a visitor that defines every single method -- even the ones you don't want to match against). Using just object equals in tests is often not an option since the test might only want to assert on parts of the value, or some fields might be things like timestamps that change (in the case of integration tests etc). The current workaround is often for testing purposes to define a visitor that throws in every method, and then in tests extend that base visitor and @Override the one (or several) methods you want to handle in the test.

What did you want to happen?

Consider adding generated methods to union types that allow you to easily test if a union object has a specific type, and retrieve the value from it. These would work by allowing the user to create a java.util.function.Consumer that accepts that type.

As a concrete example, consider this (partial) conjure object definition:

MyData:
  union:
    foo: FooType
    # ... many other subtypes follow

Methods like this could be generated on MyData:

public void ifFoo(Consumer<FooType> consumer) {
    if (value instanceof FooWrapper) {
        consumer.accept((FooWrapper) value).value);
    }
}

Similarly we could generate a method like this to throw if the object does not have that type:

public void requireFoo(Consumer<FooType> consumer) {
    if (value instanceof FooWrapper) {
        consumer.accept((FooWrapper) value).value);
    } else {
        throw new IllegalStateException(...);
    }
}

Another alternative is to auto generate an abstract visitor that throws in every method, so that you can extend that and @Override the specific methods you want.

[abless]

+1, though I'd rather have a Optional<FooType> getFoo() method instead.

@iamdanfox, are there any plans on supporting this?