Wiki

Clone wiki

bolts / DesignDecisions

Home * На русском

Design Decisions

Bolts Collections Extend JDK Collection

The main bolts difference from related projects is that bolts XxxF collections extend JDK Xxx collection, and collection operations are XxxF interface methods. Bolts collections can be passed to any external code, and collections returned by external libraries can be easily wrapped to bolts collections by calling one of Cf.x operation.

Function Types are Abstract Clases

In early versions function types (like Function2I) were interfaces. Interface give better flexibility in theory (for example, interface implementations may be generated on the fly using JDK standard tools, interfaces allow multiple inheritance). But in practice we never used such flexibility, so we made functions abstract classes.

Function Type Names

We refuced human-readable function class names like Predicate, Mapper or BinaryFunction, replacing them with Function1B, Function and Function2, because it is not possible to think up nice names for all Function* variants.

Immutability Convention

No collection method mutate collection they operate on (with rare exceptions). Methods assume that they operate on an immutable collection. So methods may return "this" collection and a view "this" collection as well as new collection.

Returned collections should be threated as immutable, and altering original collection after performing an operation (like map or drop) may harm the result collection.

This is dangerous, but we made it for better performance.

Collection Algorithm Implementations

Bolts does not implement own hashtable, linked list or tree. Bolts is a better collections interface, not the whole collection library.

Updated