Class and Type Templates
Yesterday's over my shoulder... so I can't look back for too long.
There's just too much to see... waiting in front of me...
And I know that I just can't go wrong.
- Jimmy Buffet
Class Templates
Aztec Templates provide a general purpose, parameterized class system. Using Templates makes it very easy to create a family of classes that provides similar logic or functionality, and they only differ by the type of object they are dealing with. Collections are a great example of classes that benefit tremendously from the use of templates.
♦ When a class is defined, the class name is followed by braces with one or more embedded classes. There is no separate "template" keyword - the template class parameters are embedded immediately following the class name itself (e.g. class MyTemplateClass<T> { } ).
♦ When an instance of a template class is used, each template class parameter must be filled in with an actual Aztec class (e.g. data<MyTemplateClass<Thread>> MyThreadTemplate).
When a specific instance of a real template class is used, the compiler analyzes the combination of the name and the one or more parameterized classes. If the specific instance is a new combination, the compiler, "under the covers", compiles a new instance of the template class, with these "real class(es)" used as parameters. If the combination has already been compiled, that code is reused for this instance of its use.
♦ When the new template instance is created and compiled, the system analyzes the classes that are used/referenced in all code within the new class. If the data type matches one of the template parameter classes, the class is replaced with the matching parameter class.
♦ When using a template class, the embedded class name(s) can be used with the full Aztec space (e.g. data<MyTemplateClass<aztec.system.Thread>> MyThreadTemplate).
Other than the fancy way it gets created and the fancy name, a specific instance of a template class is really just another Aztec class. Metadata exists for each instance of a template class (e.g. MyTemplateClass<Thread>).
♦ You can derive a new, non-template class from a template based parent classs (e.g. class MyThreadTemplateClass from<MyTemplateClass<Thread>> { } ).
♦ You can derive a new, non-template data type using a specific instance of a template class or type (e.g. type<MyTemplateClass<Thread>> MyThreadTemplateType).
There are several benefits to using class templates.
♦ The actual source code and business logic is written once in the template class. Each real instance of the template gets it its own physical copy of the code, as the code now pertains to the specific class or classes that were "passed into" the class, but the writer of the code only has to maintain a single copy.
♦ When using a generic List class such as ObjectList, it returns an item from the list as a "Base" class reference. The user of the list must know what type of data it is dealing with and then manually convert it to that type.
♦ The Template class solves this problem by substituting the parameterized classes that are passed into the template class upon creation into those places that use the data type. This allows the "Get()" method to return an object of the "correct" data type and the "Set()" method to take an object of the "correct" type. The correct type in this case is assumed to be based on the class or classes that are "passed into the class" when the real instance of the template class is created.
The following diagram is a simple example showing three stages of template class usage.
1) Template class is defined (TemplateClass<>)
2) A specific instance of the template class is used (Thread is the parameterized class), which triggers...
3) A real class named TemplateClass<Thread> is created automatically
There are several important classes in the Aztec framework that use templates.
♦ List<> family of collection classes
♦ Queue<> family of collection classes
♦ QuickSort<> general purpose sorting class
Type Templates
The Aztec 'type' statement also supports template definitions, with the same parameter class substitution behavior as described above for the Class statement.
The following diagram is a simple example showing three stages of template class usage.
1) Template type is defined (MethodRefWithArg<>)
2) A specific instance of the template type is used (Thread is the parameterized class), which triggers...
3) A real type named MethodRefWithArg<Thread> is created automatically
Sibling Templates
When a new instance of an Aztec template class is created, it can also create one or more related, template based classes/types using some or all of the parameter classes. When source code within the template class references one of the parameter classes from the "real instance" of the class, the system substitutes the real parameter class its place.
♦ This is commonly used in the data<> definition statement or the method<> definition statement by using the parameter class alone (e.g. "data<T> DataItem" is replaced with "data<Thread> DataItem" in the above example).
♦ This feature can also be used to reference a different template class or template type which is related to the original template class. This causes the related template class or type to be created automatically with the creation of the original template class. These related, auto-created template classes or types are referred to as Sibling Templates.
♦ This feature is used by the Queue<> family of classes. When an instance of the 'Queue<>' class is created, the system automatically creates instances of the 'QueueEvent<>' class and 'QueueHandler<>' type, using the same parameter class as was used with the creation of the Queue<> class.
♦ For example, the "data<Queue<Thread>> MyThreadQueue" statement results in the automatic creation of 'QueueEvent<Thread>' and 'QueueHandler<Thread>'.
♦ This automatic creation can work in both or multiple directions, and it does in the case of the Queue<> family of classes.
♦ Creation of the 'QueueEvent<Thread>' class automatically results in 'Queue<Thread>' class and 'QueueHandler<Thread>' type.
♦ Creation of the 'QueueHandler<Thread>' type automatically results in 'Queue<Thread>' and 'QueueEvent<Thread>' classes.
