| 196 | | Compound terms with the same functor and (usually) the same number of arguments as a parametric object identifier may act as <em>proxies</em> to a parametric object. Proxies may be stored on the database as Prolog facts and be used to represent different instantiations of a parametric object identifier. |
| | 196 | Compound terms with the same functor and (usually) the same number of arguments as a parametric object identifier may act as <em>proxies</em> to a parametric object. Proxies may be stored on the database as Prolog facts and be used to represent different instantiations of a parametric object identifier. Logtalk provides a convenient notation for accessing proxies represented as Prolog facts when sending a message: |
| | 197 | </p> |
| | 198 | <pre>{Proxy}::Message</pre> |
| | 199 | <p> |
| | 200 | In this context, the proxy argument is proved as a plain Prolog goal. If successful, the message is sent to the corresponding parametric object. Typically, the proof allows retrieving of parameter instantiations. This notation supports backtracking over the Prolog facts that unify with the proxy term. When this behavior is unwanted, is possible to commit to the first unifying fact by writing: |
| | 201 | </p> |
| | 202 | <pre>{Proxy}::(!, Message)</pre> |
| | 203 | <p> |
| | 204 | In most cases, however, the use of cuts is not necessary as this construct is usually used with a proxy argument that is partially instantiated in order to unify with a single Prolog fact. |
