Type convertor registry

1. Field of the Invention

The present invention generally relates to the conversion of data from one type to another type in computer software and, more particularly, to a generalized mechanism to manage ad-hoc type conversions in computer software.

2. Background Description

Converting data from one type, e.g., a string, to another type, e.g., a color, is a very common operation in computer software. An extremely common occurrence of this is when accepting an input in a graphical user interface (GUI) via a text field for a non-string data item such as a number.

Several categories of type conversions can be identified:

automatic type converts, where the language processor automatically converts a value of one type to be of another type by applying some conversion logic built-in to the language processor. This may be done for primitive types as well as for object types. In object systems, such conversions are limited to upward type converts in the underlying type lattice.

user-requested type converts, where the user (i.e., the application programmer) directs the compiler to convert a value of one type to be that of another type by applying either a static, user-defined or built-in convertor. This may be done for primitive types as well as object types.

ad-hoc type converts, where unrelated types of objects are converted using ad-hoc mechanisms, e.g., a string to a font. These are currently explicitly managed by the user (i.e., the application programmer versus the “system” (i.e., the language processor) programmer) by writing appropriate functions and invoking them as needed on an ad-hoc basis. In some cases, certain type conversions may be supported by library functions (e.g., converting from a string to an integer value).

As software development evolves towards the composition of off-the-shelf components, ad-hoc type conversions become ubiquitous. The current approach is very much oriented around a single programmer or programming project managing their own type conversion needs. The problem with this strategy is that it does not scale with large projects nor over time, and tends not to encourage the construction of reusable type convertors.

It is therefore an object of the present invention to provide a generalized mechanism to manage ad-hoc type conversions in computer software.

According to the invention, there is provided a management framework that separates the task of defining individual type converters from the task of locating type converters on demand. This separation is achieved by the introduction of a “type converter registry”. Type converters are added to the registry once they are defined in order to make them available for future use. Later on, type converters are retrieved on demand, by searching them in the registry according to a unique identification key.

This invention encourages and facilitates the reuse of component-oriented type conversions. It makes possible to distribute the usage of the management mechanism to either the application or the system (language processor) level. Finally, it enables run-time redefinition of the conversion algorithms (as opposed to statically defined conversions in the C++ language).

The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

FIG. 1 is a flow diagram representing the logic of the registry add process;

FIG. 2 is a flow diagram representing the logic of the lookup process in a “simple” registry according to the invention;

FIGS. 3A and 3B are diagrams representing the logic of the type converter lattice implied by the entries in the registry;

FIG. 4 is a flow diagram representing the logic of the lookup process in a “smart” registry according to the invention; and

FIG. 5 is a block diagram illustrating an example of a “distributed” or “network aware” registry according to the invention.

The registry can be realized to be of different levels of complexity, based on the needs of the environment. The first level, which we term the “simple” level, operates as shown in FIGS. 1 and 2. In FIG. 1, the [triple] tuple 100 including the source type, the destination type and the converter is registered in function block 101 , by adding it to a lookup table using the pair (source type, destination type) as the lookup key. A pre-registered converter is retrieved from the simple registry as shown in FIG. 2. A pair of types 200 (source, destination) is provided and used as the key for a table lookup. The lookup table is searched in function block 201 . In decision block 202 , a test is made to determine whether a converter was found for the requested types. If so, the converter is returned in function block 204 ; otherwise, in function block 203 , a signal is generated to inform the requesting party that no converter is available.

The next level of registry, which we refer to as the “smart” level, adds to the “simple” level by learning information from the type convertors registered into it and derives conversions that are possible by composing existing convertors. This is done by building a type convertor lattice as implied by the registered converters. FIGS. 3A and 3B represent an example type converter lattice, with the registered convertors represented in FIG. 3A, and the implied lattice shown in FIG. 3 B. Notice that by successively applying several registered type converters, new conversions become possible. For instance, the conversion from type “t” to type “s” is possible by applying a conversion from “t” to “u” followed by a conversion of type “u” to type “s”, even though conversion “t” to “s” is not registered.

The lookup operation in the smart registry is shown in FIG. 4. A tuple 400 made up of source and destination types is provided as input. In function block 401 , the lattice is searched for a path from the source type to the destination type. In decision block 402 , a test checks whether a path was found. If so, in function block 404 , the registry returns a composing converter that applies each converter along the path in sequence until the final type is achieved. Otherwise, a return is generated in function block 403 to inform the requester that no converter could be produced. Smart registries may also be aware of the host language's type lattice and use that information to augment its type convertor lattice.

The third level of registry is the “distributed” or “network-aware” registry, where either smart or simple registries may use some networked repositories to register and search type convertors. The operation is similar to the simple and smart registries described above. However, now the registry is in fact a “distributed” registry, residing not only on the local computer, but including repositories of type converters residing in other computers in a network. An example of this virtual distributed registry is shown in FIG. 5, where the local registry 501 directs lookup requests to the registries 502 to 505 in the network 500 and receives back the corresponding converters, if found.

The present invention allows the definition of any or all of these types of registries. In the following discussion, we provide a concrete realization of the invention for the Java language.

A type convertor is defined by the following interface:

public interface TypeConvertor {

public Object convert (Class from, Class to, Object obj);

}

The type convertor register is defined by the following interface:

public interface TypeConvertorRegistry {

public void register (Class from, Class to, TypeConvertor convertor);

public TypeConvertor lookup (Class from, Class to) throws BMLException;

}

BML provides a simple implementation of this interface in the following:

public class TypeConvertorRegistryImpl implements

TypeConvertorRegistry {

Hashtable reg=new Hashtable ( );

// register a convertor

public void register (Class from, Class to,

TypeConvertor convertor ) {

String key=from.tetName ( )+“→”+to.getName ( );

reg.put (key, convertor);

}

// lookup convertor

public TypeConvertor lookup (Class from, Class to) throws BMLException {

String key=from.get Name ( )+“→”+to.getName ( );

return (Typeconvertor) reg.get (key);

}

}

In other registry implementations, the lookup method may traverse a type lattice or search the network or the like.

Specific type convertors are defined as classes that implement the TypeConvertor interface. For example:

// convert from java.lang.String to

//java.awt.Color

Typeconvertor tc=new TypeConvertor ( ) {

public Object convert (Class from, Class to, Object obj) {

return Color.decode ((String) obj);

}

};

Such a convertor would be registered into a type convertor by calling the register method of the registry. For example:

TypeConvertorRegistryImpl tcr=new

TypeConvertorRegistryImpl ( );

tcr.register (java.lang.String.class,

java.awt.Color.class, tc);

When it is necessary to locate and apply a type convertor, the registry is consulted and the returned type convertor is invoked. For example:

Typeconvertor tc=tcr.lookup

(java.lang.String.class, java.awt.Color.class);

color cf=tc.convert (java.lang.String.class,

java.awt.Color.class,0×ff0000″);

While the invention has been described in terms of preferred embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.