org.organicdesign.fp.either.package.html Maven / Gradle / Ivy
Show all versions of UncleJim Show documentation
This approximates union of two types for Java - for when something (e.g. a return type) can be
exactly one of a number of things.
Java has specifically avoided union types in favor of defining a super-type and making those
other two types extend the new parent. But sometimes you don't have control of the two types to
make them inherit from a common ancestor. Sometimes, one hierarchy makes sense in one context
and another hierarchy makes sense in another.
For example, in the Serialization code for PersistentVector, we use a SerializationProxy to
handle the actual serialization and deserialization of PersistentVectors. Our proxy has
a transient (in the serialization sense) ImList variable. When serializing, it holds an
immutable vector. When deserializing, it holds a MutableVector for speed. In the context
of that code, it makes sense to treat the mutable and immutable vector the same. So the
Mutable class could subclass the immutable one.
But if a method says it returns an Immutable object, we don't want to get a Mutable one by
accident. So that would be the opposite inheritance hierarchy. Really, we want to move
to a type system where types are sets so that you can have an ImmutableOrMutable type and
a OnlyImmutable type and have PersistentVector be one in one circumstance and the other in
the other circumstance. ML had this in 1990. Haskell took it from there. Then Object Oriented
programming took the world by storm and no-one had any interest in types without Objects.
In retrospect, we may have missed something.
If you like Paguro and are interested in a new JVM and maybe compile-to-JavaScript language
with Union and Intersection types instead of Object Oriented hierarchies, take a look at the
evolving spec for the
Cymling programming
language. It may need some help to become reality.