Currently, there is no modeling means to retrofit LEMMA with types from external libraries. Instead, model processors must always be adapted to support such types. For example, to support code generation for the type LocalDate from Java's Time API, it is required to extend the Java Base Generator class TypeMappings with an entry like
However, it would be nice to support the specification of types originating from a library of a certain technology (e.g., the standard lib of the Java technology) directly within technology models, e.g., via a new type kind library and with additional library types (that in the case of Java result in additional imports) so that one could write:
...
types {
...
library type LocalDate from library "java.time"
with additional types "org.example.LibraryClass1", "org.example.LibraryClass2";
}
...
or in the form of "external types", e.g.,
...
types {
...
external type LocalDate with fully-qualified name "java.time.LocalDate"
requiring "org.example.LibraryClass1", "org.example.LibraryClass2";
}
...
Currently, there is no modeling means to retrofit LEMMA with types from external libraries. Instead, model processors must always be adapted to support such types. For example, to support code generation for the type LocalDate from Java's Time API, it is required to extend the Java Base Generator class TypeMappings with an entry like
and the have a technology model with
However, it would be nice to support the specification of types originating from a library of a certain technology (e.g., the standard lib of the Java technology) directly within technology models, e.g., via a new type kind
library
and with additional library types (that in the case of Java result in additional imports) so that one could write:or in the form of "external types", e.g.,