Package org.organicdesign.fp.oneOf

This approximates union types for Java - for when something (e.g.

See: Description

Interface Summary

Interface	Description
Option<T>	Indicates presence or absence of a value (null is a valid, present value).

Class Summary

Class	Description
OneOf2<A,B>	Like Tuple2, OneOf2 is designed to be sub-classed so you can add descriptive names.
Option.None<T>	Represents the absence of a value
Option.Some<T>	Represents the presence of a value, even if that value is null.
Or<G,B>	`Or` represents the presence of a successful outcome, or an error.

Package org.organicdesign.fp.oneOf Description

This approximates union types for Java - for when something (e.g. a return type) can be exactly one of some number of things. This is NOT variance or inheritance (Cars and Trucks are Vehicles), this is one un-related thing or another (a set of things that are either Trucks OR Happiness).

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 (like Trucks and Happiness). 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. Haskelltook it from there. Then Object Oriented programming took the world by storm and in types without Objects waned. 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.