PCE version 4C man_modulenamespaceid_tablemodified current_idOIxN class/hyperN referenceC hash_tablerefersizeOIxaI sN V.hyper.toCman_variable_card identifiermodule last_modifiednamesummary descriptionsee_alsoinheritdefaultsOIxN V.hyper.toRICdateOIx,êsNtonnnCchainsizeOIxIEN V.hyper.fromXnsNM.hyper.S._save_relationCman_method_card identifiermodule last_modifiednamesummary descriptionsee_alsoinherit diagnosticsdefaultsbugsOIxNM.hyper.S._save_relationRIOIx-> ØN_save_relationnCstringOIxdConsider saving relation (->save_in_file). A hyper is saved only if both <-from and <-to are saved.nnnnnsNV.hyper.forward_nameOI xNV.hyper.forward_nameRIOI x,êjN forward_namenOI x-Name of the hyper as seen from object <-from.nnnsN V.hyper.fromOI xN V.hyper.fromRIOI x,ê­NfromnOIxThe variables <-from and <-to define the two objects related by the hyper-link. `object <-hypered' may be used to find hyper-links from the related objects.nnnsNC.hyperCman_class_card identifiermodule last_modifiednamesummary descriptionsee_alsoinherituser_interfacebugsOIxNC.hyperRIOIx0µ­¯NhypernOIxöA hyper object is a named binary link between two objects. Where slot-references and attribute relations are uni-directed, a hyper may be regarded a two-way `object ->attribute'. Hypers are used for two purposes: * The creation of hyper-text networks * An attribute is a useful instrument to register a `slave' object. Because the value of the attribute does not know about the `main' object, hypers are a suitable solution for circumstances where this knowledge is required. As an example of the second case, consider an application that creates a secondary window to allow for editing some object of the main window. If the user is allowed to work in both window and destroy both windows separately, a hyper is a suitable way to maintain the relation between both windows. The most important behaviour dealing with hypers is defined on class object: `object ->send_hyper' Broadcast a message over hypers `object <-get_hyper' Idem to get information `object <-hypered' Find hyperlinks from objectOIxIeN$class/constraint$C.constrainteN $class/interceptor$C.interceptorEN#$class/object$M.object.G.all_hypersXnnnsNM.hyper.S.unlink_fromOIxNM.hyper.S.unlink_fromRIOIx2‘©éN unlink_fromnOIx!Called from the object-management system if the <-from (->unlink_from) or the <-to (->unlink_to) side of the hyper is being destroyed. Both methods simply destroy the hyper object. These methods may be redefined, but always should destroy the hyper by calling free/1. The example below defines a subclass between a `whole' and a `part', where destruction of the whole automatically destroys the part. :- pce_begin_class(part_hyper, hyper). unlink_from(H) :-> get(H, to, Part), free(Part), free(H). :- pce_end_class. A simple example using the code above: ?- send(new(V1, view(hello)), open), send(new(P1, picture(world)), open), new(_, part_hyper(V1, P1, part, whole)). V1 = @435643 P1 = @465732 Now the following call will delete both windows: ?- send(@435643, free).nnnnnsNV.hyper.backward_nameOIxNV.hyper.backward_nameRIOIx,êRN backward_namenOIxoHyper-name seen from the <-to object. By default the name is the same in both directions. See <-forward_name.nnnsNM.hyper.S.initialiseOIxNM.hyper.S.initialiseRIOIx,ëN initialisenOIxâCreate a hyper-link from <-from to <-to. Seen from <-from, the link is named <-forward_name, seen from <-to it is called <-backward_name. This method will invoke `object ->attach_hyper' on both objects to register the hyper.nnnnnsNM.hyper.S.unlink_toOIxNM.hyper.S.unlink_toRIOIx,ë…N unlink_tonnnOIxIENM.hyper.S.unlink_fromXnnnsNM.hyper.S.unlinkOIxNM.hyper.S.unlinkRIOI x0…NunlinknOI!x‹Destroy the hyper object and disconnect it from the related objects using `object ->delete_hyper'. See also ->unlink_from and ->unlink_to.nnnnnXaCnumber O I"xx