Tea 4.0

New and Noteworthy in 4.0

Generics

Tea now supports the notion of generics as defined by Java. Note that generics is a purely syntactic, compile-time feature and no guarantees are made at runtime. Tea uses generics in two ways. First, it allows casting and type definitions to include a generic signature such as collections.

list = result as List<String>

In this case, the list will be known as a list of String instances. This is helpful as the second way generics are used is through loops. If generics are used on a collection type, then Tea will infer the data type from the generic signature. Previously collections always resulted in Object being used requiring explicit casting. Generics remove this restriction.

foreach (item in list) {
    ‘LENGTH: ‘ item.length
}

Generics will also work on other data types. Consider the following interface:

public interface Data<T> {
    T getData();
}

A given context of an application could implement that interface as:

public DataContext<T extends Number> implements Data<T> {
    T getData() { return … }
}

Tea can now invoke getData on the context and be able to properly infer that getData returns a type of Number removing an explicit cast from the template. For example:

sum = a.getData() + b.getData()

The one part of generics that are not yet supported is type inference from method arguments. For example, the following signature returns the proper type based on the given parameter.

public <T> T getInstance(Class<T> type)

However, in Tea, that will always return Object as it is unable to infer that it should return the same argument as the supplied type.

Auto Imports

Tea by defaults imports the java.lang and java.util packages. This means that classes within those packages do not need explicit typing. For example:

a = null as List

This has now been extended to allow the configuration file to specify other imported packages that will be assumed to have been imported. The order is important as Tea will match the first class within the first available package that is valid. However, you can always fully-qualify the package to avoid those collisions. Auto imports are important as it reduces the reliance of developers knowing packaging. Developers should not care about what a given package or namespace is in. Auto imports removes that. The list of expected data types can now be pre-specified avoiding that qualification. For more information, see the configuration document.