Categories provide a way to encapsulate a set of related predicate definitions that do not represent an object and that only make sense when composed with other predicates. Categories may also be used to break a complex object in functional units. A category can be imported by several objects (without code duplication), including objects participating in prototype or class-based hierarchies. This concept of categories shares some ideas with Smalltalk-80 functional categories <ahref="../bibliography.html#Goldberg83">[Goldberg 83]</a>, Flavors mix-ins <ahref="../bibliography.html#Moon86">[Moon 86]</a> (without necessarily implying multi-inheritance) and Objective-C categories <ahref="../bibliography.html#Cox86">[Cox 86]</a>. There are no pre-defined categories in Logtalk.
We can define a new object in the same way we write Prolog code: by using a text editor. Logtalk source files may contain one or more objects, categories, or protocols. If you prefer to define each entity in its own source file, it is recommended that the file be named after the category. By default, all Logtalk source files use the extension <code>.lgt</code> but this is optional and can be set in the configuration files. Compiled source files (by the Logtalk preprocessor) have, by default, a <code>.pl</code> extension. Again, this can be set to match the needs of a particular Prolog compiler in the corresponding configuration file. For instance, we may define a category named <code>documenting</code> and save it in a <code>documenting.lgt</code> source file that will be compiled to a <code>documenting.pl</code> Prolog file.
Category names must be atoms. Objects, categories, and protocols share the same name space: we can not have a category with the same name as an object or a protocol.
Category code (directives and predicates) is textually encapsulated by using two Logtalk directives: <atitle="Consult reference manual"href="../refman/directives/category1_3.html"><code>category/1-3</code></a> and <atitle="Consult reference manual"href="../refman/directives/end_category0.html"><code>end_category/0</code></a>. The most simple category will be one that is self-contained, not depending on any other Logtalk entity:
This feature should only be used when extending a category without breaking its functional cohesion (for example, when a modified version of a category is needed for importing on several unrelated objects). The prefered way of composing several categories is by importing them into an object.
Categories cannot inherit from objects. In addition, categories cannot contain clauses for dynamic predicates. This restriction applies because a category can be imported by several objects and because we cannot use the database handling built-in methods with categories (messages can only be sent to objects). However, categories may contain declarations for dynamic predicates and they can contain predicates which handle dynamic predicates. For example:
Each object importing this category will have its own <code>attribute_/2</code> private, dynamic predicate. The predicates <code>attribute/2</code>, <code>set_attribute/2</code>, and <code>del_attribute/2</code> always access and modify the dynamic predicate contained in the object receiving the corresponding messages.
We can find, by backtracking, all defined categories by using the <atitle="Consult reference manual"href="../refman/builtins/current_category1.html"><code>current_category/1</code></a> Logtalk built-in predicate with an uninstantiated variable:
A category can be dynamically created at runtime by using the <atitle="Consult reference manual"href="../refman/builtins/create_category4.html"><code>create_category/4</code></a> built-in predicate:
The first argument, the name of the new category - a Prolog atom - should not match with an existing entity name. The remaining three arguments correspond to the relations described in the opening category directive and to the category code contents (directives and clauses).
If we need to create a lot of (dynamic) categories at runtime, then is best to to define a metaclass or a prototype with a predicate that will call this built-in predicate in order to provide more sophisticated behavior.
Dynamic categories can be abolished using the <atitle="Consult reference manual"href="../refman/builtins/abolish_category1.html"><code>abolish_category/1</code></a> built-in predicate:
We can define a goal to be executed as soon as a category is (compiled and) loaded to memory with the <atitle="Consult reference manual"href="../refman/directives/initialization1.html"><code>initialization/1</code></a> directive:
As usually happens with Prolog code, a category can be either static or dynamic. A category created during the execution of a program is always dynamic. A category defined in a file can be either dynamic or static. Dynamic categories are declared by using the <atitle="Consult reference manual"href="../refman/directives/dynamic0.html"><code>dynamic/0</code></a> directive in the category source code:
The directive must precede any predicate directives or clauses. Please be aware that using dynamic code implies a performance hit when compared to static code. We should only use dynamic categories when these need to be abolished during program execution.
Besides the relations declared in the category opening directive, the predicate definitions contained in the category may imply other dependencies. This can be documented by using the <atitle="Consult reference manual"href="../refman/directives/calls1.html"><code>calls/1</code></a> and the <atitle="Consult reference manual"href="../refman/directives/uses1.html"><code>uses/1</code></a> directives.
</p>
<p>
The <code>calls/1</code> directive can be used when a predicate definition sends a message that is declared in a specific protocol:
A category can be documented with arbitrary user-defined information by using the <atitle="Consult reference manual"href="../refman/directives/info1.html"><code>info/1</code></a> directive:
Logtalk provides two sets of built-in predicates that enable us to query the system about the possible relationships that a category can have with other entities.
</p>
<p>
The built-in predicates <atitle="Consult reference manual"href="../refman/builtins/implements_protocol2_3.html"><code>implements_protocol/2</code></a> and <atitle="Consult reference manual"href="../refman/builtins/implements_protocol2_3.html"><code>implements_protocol/3</code></a> find which categories implements which protocols:
Note that, if we use an uninstantiated variable for the first argument, we will need to use the <atitle="Consult reference manual"href="../refman/builtins/current_category1.html"><code>current_category/1</code></a> built-in predicate to ensure that the returned entity is a category and not an object.
We can find the properties of defined categories by calling the built-in predicate <atitle="Consult reference manual"href="../refman/builtins/category_property2.html"><code>category_property/2</code></a>:
A category may have the property <code>static</code>, <code>dynamic</code>, or <code>built_in</code>. Dynamic categories can be abolished in runtime by calling the <atitle="Consult reference manual"href="../refman/builtins/abolish_category1.html"><code>abolish_category/1</code></a> built-in predicate.
To make all public predicates imported via a category protected or to make all public and protected predicates private we prefix the category's name with the corresponding keyword:
