In Quintus Objects, by default, a class inherits all the methods of its superclass. The programmer has more control over the inheritance of methods than the inheritance of slots, however. In particular, methods can be uninherited and they can be redefined.
To prevent a method from being inherited, use the uninherit/1
directive. For example, suppose that the class point is defined as
before. That is, its definition begins as follows:
:- class point =
[public x:float=0,
public y:float=0].
Because both slots are public, a put method is automatically generated for each, which allows their values to be changed.
The definition of a new class fixed_point might begin as follows:
:- class fixed_point = point.
:- uninherit
point << (x/l),
point << (y/l).
Self <- create(X, Y) :-
store_slot(x, X),
store_slot(y, Y).
The parentheses are necessary because of the precedences of the << and
/ operators.
Because the put methods from point are not inherited, no instance of
the fixed_point class can change its x and y values once
created--unless the class definition contains another method for doing
so. The get methods are inherited from point, however.
To redefine a method, simply include method clauses for its message within a class's definition. The new method clauses replace, or shadow, the inherited method clauses for this class.
Another way to prevent the x and y slots of the
fixed_point class from being modified would be to shadow the put
methods. For example, they might be redefined as
Self << x(_) :-
format(user_error, "cannot modify x slot value.~n.", []),
fail.
Self << y(_) :-
format(user_error, "cannot modify y slot value.~n", []),
fail.
Now attempts to modify the x or y values of a fixed point
object generate a specific error message and fail. A more complicated
version would raise an appropriate exception.