Categories

Categories are fine-grained units of code reuse and can be regarded as a dual concept of protocols. Categories provide a way to encapsulate a set of related predicate declarations and definitions that do not represent a complete object and that only make sense when composed with other predicates. Categories may also be used to break a complex object into 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 [Goldberg83], Flavors mix-ins [Moon86] (without necessarily implying multi-inheritance), and Objective-C categories [Cox86]. Categories may also complement existing objects, thus providing a hot patching mechanism inspired by the Objective-C categories functionality.

Logtalk defines a built-in category, core_messages, which is described at the end of this section.

Defining a new category

We can define a new category 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 .lgt but this is optional and can be set in the adapter files. Intermediate Prolog source files (generated by the Logtalk compiler) have, by default, a _lgt suffix and a .pl extension. Again, this can be set to match the needs of a particular Prolog compiler in the corresponding adapter file. For example, we may define a category named documenting and save it in a documenting.lgt source file that will be compiled to a documenting_lgt.pl Prolog file (depending on the backend compiler, the names of the intermediate Prolog files may include a directory hash and a process identifier to prevent file name clashes when embedding Logtalk applications or running parallel Logtalk processes).

Category names can be atoms or compound terms (when defining parametric categories). Objects, categories, and protocols share the same name space: we cannot 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: category/1-4 and end_category/0. The most simple category will be one that is self-contained, not depending on any other Logtalk entity:

:- category(Category).
    ...
:- end_category.

If a category implements one or more protocols, then the opening directive will be:

:- category(Category,
    implements([Protocol1, Protocol2, ...])).
    ...
:- end_category.

A category may be defined as a composition of other categories by writing:

:- category(Category,
    extends([Category1, Category2, ...])).
    ...
:- end_category.

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 preferred way of composing several categories is by importing them into an object. When a category overrides a predicate defined in an extended category, the overridden definition can still be called by using the (^^)/1 control construct.

Categories cannot inherit from objects. In addition, categories cannot define 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). A consequence of this restriction is that a category cannot declare a predicate (or non-terminal) as both multifile and dynamic. However, categories may contain declarations for dynamic predicates, and they can contain predicates that handle dynamic predicates. For example:

:- category(attributes).

    :- public(attribute/2).
    :- public(set_attribute/2).
    :- public(del_attribute/2).

    :- private(attribute_/2).
    :- dynamic(attribute_/2).

    attribute(Attribute, Value) :-
        % called in the context of "self"
        ::attribute_(Attribute, Value).

    set_attribute(Attribute, Value) :-
        % retract old clauses in "self"
        ::retractall(attribute_(Attribute, _)),
        % assert new clause in "self"
        ::assertz(attribute_(Attribute, Value)).

    del_attribute(Attribute, Value) :-
        % retract clause in "self"
        ::retract(attribute_(Attribute, Value)).

:- end_category.

Each object importing this category will have its own attribute_/2 private and dynamic predicate. The predicates attribute/2, set_attribute/2, and del_attribute/2 always access and modify the dynamic predicate contained in the object receiving the corresponding messages (i.e., self). But it’s also possible to define predicates that handle dynamic predicates in the context of this instead of self. For example:

:- category(attributes).

    :- public(attribute/2).
    :- public(set_attribute/2).
    :- public(del_attribute/2).

    :- private(attribute_/2).
    :- dynamic(attribute_/2).

    attribute(Attribute, Value) :-
        % call in the context of "this"
        attribute_(Attribute, Value).

    set_attribute(Attribute, Value) :-
        % retract old clauses in "this"
        retractall(attribute_(Attribute, _)),
        % asserts clause in "this"
        assertz(attribute_(Attribute, Value)).

    del_attribute(Attribute, Value) :-
        % retract clause in "this"
        retract(attribute_(Attribute, Value)).

:- end_category.

When defining a category that declares and handles dynamic predicates, working in the context of this ties those dynamic predicates to the object importing the category, while working in the context of self allows each object inheriting from the object that imports the category to have its own set of clauses for those dynamic predicates.

Hot patching

A category may also explicitly complement one or more existing objects, thus providing hot patching functionality inspired by Objective-C categories:

:- category(Category,
    complements([Object1, Object2, ....])).
    ...
:- end_category.

This allows us to add missing directives (e.g., to define aliases for complemented object predicates), replace broken predicate definitions, add new predicates, and add protocols and categories to existing objects without requiring access or modifications to their source code. Common scenarios are adding logging or debugging predicates to a set of objects. Complemented objects need to be compiled with the complements compiler flag set allow (to allow both patching and adding functionality) or restrict (to allow only adding new functionality). A complementing category takes preference over a previously loaded complementing category for the same object, thus allowing patching a previous patch if necessary.

When replacing a predicate definition, it is possible to call the overridden definition in the object from the new definition in the category by using the (@)/1 control construct. This construct is only meaningful when used within categories and requires a compile-time bound goal argument, which is called in this (i.e., in the context of the complemented object or the object importing a category). As an example, consider the following object:

:- object(bird).

    :- set_logtalk_flag(complements, allow).

    :- public(make_sound/0).
    make_sound :-
        write('Chirp, chirp!'), nl.

:- end_object.

We can use the (@)/1 control construct to wrap the original make_sound/0 predicate definition by writing:

:- category(logging,
    complements(bird)).

    make_sound :-
        write('Started making sound...'), nl,
        @make_sound,
        write('... finished making sound.'), nl.

:- end_category.

After loading the object and the category, calling the make_sound/0 predicate will result in the following output:

| ?- bird::make_sound.

Started making sound...
Chirp, chirp!
... finished making sound.
yes

Note that super calls from predicates defined in complementing categories lookup inherited definitions as if the calls were made from the complemented object instead of the category ancestors. This allows more comprehensive object patching. But it also means that, if you want to patch an object so that it imports a category that extends another category and uses super calls to access the extended category predicates, you will need to define a (possibly empty) complementing category that extends the category that you want to add.

An unfortunate consequence of allowing an object to be patched at runtime using a complementing category is that it disables the use of static binding optimizations for messages sent to the complemented object, as it can always be later patched, thus rendering the static binding optimizations invalid.

Another important caveat is that, while a complementing category can replace a predicate definition, local callers of the replaced predicate will still call the non-patched version of the predicate. This is a consequence of the lack of a portable solution at the backend Prolog compiler level for replacing static predicate definitions.

Finding defined categories

We can find, by backtracking, all defined categories by using the current_category/1 built-in predicate with an unbound argument:

| ?- current_category(Category).

This predicate can also be used to test if a category is defined by calling it with a valid category identifier (an atom or a compound term).

Creating a new category in runtime

A category can be dynamically created at runtime by using the create_category/4 built-in predicate:

| ?- create_category(Category, Relations, Directives, Clauses).

The first argument should be either a variable or the name of the new category (a Prolog atom, which must 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).

For example, the call:

| ?- create_category(
         ccc,
         [implements(ppp)],
         [private(bar/1)],
         [(foo(X):-bar(X)), bar(1), bar(2)]
     ).

is equivalent to compiling and loading the category:

:- category(ccc,
    implements(ppp)).

    :- dynamic.

    :- private(bar/1).

    foo(X) :-
        bar(X).

    bar(1).
    bar(2).

:- end_category.

If we need to create a lot of (dynamic) categories at runtime, then it is best to define a metaclass or a prototype with a predicate that will call this built-in predicate in order to provide more sophisticated behavior.

Abolishing an existing category

Dynamic categories can be abolished using the abolish_category/1 built-in predicate:

| ?- abolish_category(Category).

The argument must be an identifier of a defined dynamic category; otherwise, an error will be thrown.

Category directives

Category directives are used to define category properties, document category dependencies on other Logtalk entities, and load the contents of files into a category.

Dynamic categories

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 dynamic/0 directive in the category source code:

:- dynamic.

The directive must precede any predicate directives or clauses. Please be aware that using dynamic code results in a performance hit when compared to static code. We should only use dynamic categories when these need to be abolished during program execution.

Category documentation

A category can be documented with arbitrary user-defined information by using the info/1 entity directive. See the Documenting section for details.

Loading files into a category

The include/1 directive can be used to load the contents of a file into a category. See the Objects section for an example of using this directive.

Declaring object aliases

The uses/1 directive can be used to declare object aliases. The typical uses of this directive are to shorten long object names and to simplify experimenting with different object implementations of the same protocol when using explicit message-sending.

Category relationships

Logtalk provides two sets of built-in predicates that enable us to query the system about the relationships that a category has with other entities.

The built-in predicates implements_protocol/2-3 and conforms_to_protocol/2-3 allow us to find which categories implement which protocols:

| ?- implements_protocol(Category, Protocol, Scope).

or, if we also want to consider inherited protocols:

| ?- conforms_to_protocol(Category, Protocol, Scope).

Note that, if we use an unbound first argument, we will need to use the current_category/1 built-in predicate to ensure that the returned entity is a category and not an object.

To find which objects import which categories, we can use the imports_category/2-3 built-in predicates:

| ?- imports_category(Object, Category).

or, if we also want to know the importation scope:

| ?- imports_category(Object, Category, Scope).

Note that a category may be imported by several objects.

To find which categories extend other categories, we can use the extends_category/2-3 built-in predicates:

| ?- extends_category(Category1, Category2).

or, if we also want to know the extension scope:

| ?- extends_category(Category1, Category2, Scope).

Note that a category may be extended by several categories.

To find which categories explicitly complement existing objects we can use the complements_object/2 built-in predicate:

| ?- complements_object(Category, Object).

Note that a category may explicitly complement several objects.

Category properties

We can find the properties of defined categories by calling the built-in predicate category_property/2:

| ?- category_property(Category, Property).

The following category properties are supported:

static

The category is static

dynamic

The category is dynamic (and thus can be abolished in runtime by calling the abolish_category/1 built-in predicate)

built_in

The category is a built-in category (and thus always available)

file(Path)

Absolute path of the source file defining the category (if applicable)

file(Basename, Directory)

Basename and directory of the source file defining the category (if applicable); Directory always ends with a /

lines(BeginLine, EndLine)

Source file begin and end lines of the category definition (if applicable)

directive(BeginLine, EndLine)

Source file begin and end lines of the category opening directive (if applicable)

events

Messages sent from the category generate events

source_data

Source data available for the category

public(Resources)

List of public predicates and operators declared by the category

protected(Resources)

List of protected predicates and operators declared by the category

private(Resources)

List of private predicates and operators declared by the category

declares(Predicate, Properties)

List of properties for a predicate declared by the category

defines(Predicate, Properties)

List of properties for a predicate defined by the category

includes(Predicate, Entity, Properties)

List of properties for an object multifile predicate that are defined in the specified entity (the properties include number_of_clauses(Number), number_of_rules(Number), lines(Start,End), and line_count(Start) with Start being the begin line of the first multifile predicate clause)

provides(Predicate, Entity, Properties)

List of properties for other entity multifile predicate that are defined in the category (the properties include number_of_clauses(Number), number_of_rules(Number), lines(Start,End), and``line_count(Start)`` with Start being the begin line of the first multifile predicate clause)

alias(Entity, Properties)

List of properties for an entity alias declared by the object (the properties include object in case of an object alias, module in case of a module alias, for(Original), lines(Start,End), and line_count(Start) with Start being the begin line of the uses/1 or use_module/1 directive)

alias(Predicate, Properties)

List of properties for a predicate alias declared by the category (the properties include predicate, for(Original), from(Entity), non_terminal(NonTerminal), lines(Start,End), and line_count(Start) with Start being the begin line of the alias directive)

calls(Call, Properties)

List of properties for predicate calls made by the category (Call is either a predicate indicator or a control construct such as (::)/1-2 or (^^)/1 with a predicate indicator as argument; note that Call may not be ground in case of a call to a control construct where its argument is only know at runtime; the properties include caller(Caller), alias(Alias), non_terminal(NonTerminal), lines(Start,End), and line_count(Start) with Caller, Alias, and NonTerminal being predicate indicators and Start being the begin line of the predicate clause or directive making the call)

updates(Predicate, Properties)

List of properties for dynamic predicate updates (and also access using the clause/2 predicate) made by the object (Predicate is either a predicate indicator or a control construct such as (::)/1-2 or (:)/2 with a predicate indicator as argument; note that Predicate may not be ground in case of a control construct argument only know at runtime; the properties include updater(Updater), alias(Alias), non_terminal(NonTerminal), lines(Start,End), and line_count(Start) with Updater being a (possibly multifile) predicate indicator, Alias and NonTerminal being predicate indicators, and Start being the begin line of the predicate clause or directive updating the predicate)

number_of_clauses(Number)

Total number of predicate clauses defined in the category (includes both user-defined clauses and auxiliary clauses generated by the compiler or by the expansion hooks but does not include clauses for multifile predicates defined for other entities or clauses for the category own multifile predicates contributed by other entities)

number_of_rules(Number)

Total number of predicate rules defined in the category (includes both user-defined rules and auxiliary rules generated by the compiler or by the expansion hooks but does not include rules for multifile predicates defined for other entities or rules for the category own multifile predicates contributed by other entities)

number_of_user_clauses(Number)

Total number of user-defined predicate clauses defined in the category (does not include clauses for multifile predicates defined for other entities or clauses for the category own multifile predicates contributed by other entities)

number_of_user_rules(Number)

Total number of user-defined predicate rules defined in the category (does not include rules for multifile predicates defined for other entities or rules for the category own multifile predicates contributed by other entities)

Some properties, such as line numbers, are only available when the category is defined in a source file compiled with the source_data flag turned on. Moreover, line numbers are only supported in backend Prolog compilers that provide access to the start line of a read term. When such support is not available, the value -1 is returned for the start and end lines.

The properties that return the number of clauses (rules) report the clauses (rules) textually defined in the object for both multifile and non-multifile predicates. Thus, these numbers exclude clauses (rules) for multifile predicates contributed by other entities.

Importing categories

Any number of objects can import a category. In addition, an object may import any number of categories. The syntax is very simple:

:- object(Object,
    imports([Category1, Category2, ...])).
    ...
:- end_object.

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:

:- object(Object,
    imports(private::Category)).
    ...
:- end_object.

or:

:- object(Object,
    imports(protected::Category)).
    ...
:- end_object.

Omitting the scope keyword is equivalent to writing:

:- object(Object,
    imports(public::Category)).
    ...
:- end_object.

Calling category predicates

Category predicates can be called from within an object by sending a message to self or using a super call. Consider the following category:

:- category(output).

    :- public(out/1).

    out(X) :-
        write(X), nl.

:- end_category.

The predicate out/1 can be called from within an object importing the category by simply sending a message to self. For example:

:- object(worker,
    imports(output)).

    ...
    do(Task) :-
        execute(Task, Result),
        ::out(Result).
    ...

:- end_object.

This is the recommended way of calling a category predicate that can be specialized/overridden in a descendant object, as the predicate definition lookup will start from self.

A direct call to a predicate definition found in an imported category can be made using the (^^)/1 control construct. For example:

:- object(worker,
    imports(output)).

    ...
    do(Task) :-
        execute(Task, Result),
        ^^out(Result).
    ...

:- end_object.

This alternative should only be used when the user knows a priori that the category predicates will not be specialized or redefined by descendant objects of the object importing the category. Its advantage is that, when the optimize flag is turned on, the Logtalk compiler will try to optimize the calls by using static binding. When dynamic binding is used due to e.g. the lack of sufficient information at compilation time, the performance is similar to calling the category predicate using a message to self (in both cases, a predicate lookup caching mechanism is used).

Parametric categories

Category predicates can be parameterized in the same way as object predicates by using a compound term as the category identifier where all the arguments of the compound term are variables. These variables, the category parameters, can be accessed by calling the parameter/2 or this/1 built-in local methods in the category predicate clauses or by using parameter variables.

Category parameter values can be defined by the importing objects. For example:

:- object(speech(Season, Event),
    imports([dress(Season), speech(Event)])).
    ...
:- end_object.

Note that access to category parameters is only possible from within the category. In particular, calls to the this/1 built-in local method from category predicates always access the importing object identifier (and thus object parameters, not category parameters).

Built-in categories

Logtalk defines a built-in category that is always available for any application.

The built-in category core_messages

The built-in core_messages category provides default translations for all compiler and runtime printed messages, such as warnings and errors. It does not define any public predicates.