io.virtdata.libraryimpl

Class ComposerLibrary

java.lang.Object

io.virtdata.libraryimpl.ComposerLibrary

All Implemented Interfaces:

DataMapperLibrary

@AutoService(value=io.virtdata.api.DataMapperLibrary.class)
public class ComposerLibrary
extends Object
implements DataMapperLibrary

Synopsis

This library implements the ability to compose a lambda function from a sequence of other functions. The resulting lambda will use the specialized primitive function interfaces, such as LongUnaryOperator, LongFunction, etc. Where there are two functions which do not have matching input and output types, the most obvious conversion is made. This means that while you are able to compose a LongUnaryOperator with a LongUnaryOperator for maximum efficiency, you can also compose LongUnaryOperator with an IntFunction, and a best effort attempt will be made to do a reasonable conversion in between.

Limitations

Due to type erasure, it is not possible to know the generic type parameters for non-primitive functional types. These include IntFunction<?>, LongFunction<?>, and in the worst case, Function<?,?>. For these types, annotations are provided to better inform the runtime lambda compositor.

Multiple Paths

The library allows for there to be multiple functions which match the spec, possibly because multiple functions have the same name, but exist in different libraries or in different packages within the same library. This means that the composer library must find a connecting path between the functions that can match at each stage, disregarding all but one.

Path Finding

The rule for finding the best path among the available functions is as follows, at each pairing between adjacent stages of functions:

1. The co-compatible output and input types between the functions are mapped. Functions sharing the co-compatible types are kept in the list. Functions not sharing them are removed.
2. As long as functions can be removed in this way, the process iterates through the chain, starting again at the front of the list.
3. When no functions can be removed due to lack of co-compatible types, each stage is selected according to type preferences as represented in ValueType
4. If the next (outer) function does not have a compatible input type, move it down on the list. If, after this step, there are functions which do have matching signatures, all others are removed.

Constructor Summary

Constructors

Constructor and Description
ComposerLibrary()

Method Summary

Modifier and Type	Method and Description
boolean	canParseSpec(String spec)
List<String>	getDataMapperNames()
String	getLibraryName()
Optional<ResolvedFunction>	resolveFunction(String specline)
List<ResolvedFunction>	resolveFunctions(String spec)

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Methods inherited from interface io.virtdata.api.DataMapperLibrary

getDataMapper

Constructor Detail

ComposerLibrary

public ComposerLibrary()

Method Detail

getLibraryName

public String getLibraryName()

Specified by:

getLibraryName in interface DataMapperLibrary

canParseSpec

public boolean canParseSpec(String spec)

Specified by:

canParseSpec in interface DataMapperLibrary

resolveFunctions

public List<ResolvedFunction> resolveFunctions(String spec)

Specified by:

resolveFunctions in interface DataMapperLibrary

resolveFunction

public Optional<ResolvedFunction> resolveFunction(String specline)

Specified by:

resolveFunction in interface DataMapperLibrary

getDataMapperNames

public List<String> getDataMapperNames()

Specified by:

getDataMapperNames in interface DataMapperLibrary