| Both sides previous revision Previous revision | |
| user_guide:extend:rulefiles [2019/01/25 17:06] – ↷ Links adapted because of a move operation oroehrig | user_guide:extend:rulefiles [2021/01/12 15:38] (current) – external edit 127.0.0.1 |
|---|
| .. Note that applications the current one really depends on, that is, //imported// or //used// ones, must not be listed in such guard. | .. Note that applications the current one really depends on, that is, //imported// or //used// ones, must not be listed in such guard. |
| ==== Configuration ==== | ==== Configuration ==== |
| Rulefiles may contain configurable settings, which can be filled automatically and manipulated by the user. There are two kinds of items related to configuration: [[:general#custom_variables|custom variables]] and auto-configuration blocks. Declarations of custom variables should be preceded with comments, which are copied into the user's settings files for the sake of better legibility. | Rulefiles may contain configurable settings, which can be filled automatically and manipulated by the user. There are two kinds of items related to configuration: [[:user_guide:howto:shell_custom#custom_variables|custom variables]] and auto-configuration blocks. Declarations of custom variables should be preceded with comments, which are copied into the user's settings files for the sake of better legibility. |
| |
| ? ''custom $var = default_value;'' | ? ''custom $var = default_value;'' |
| ? ''label'' name | ? ''label'' name |
| :: Introduces a top-level name for labels, used in definitions of production rules and user methods. | :: Introduces a top-level name for labels, used in definitions of production rules and user methods. |
| ? ''prefer'' [[:general#preferences|label expression]] | ? ''prefer'' [[:user_guide:howto:shell_custom#preferences|label expression]] |
| :: Establishes a default preference list for a certain group of competing rules or user methods. The syntax of the //label expression// is the same as in the interactive commands ''prefer'' and ''prefer_now'', but here you should not enclose it in quotes nor put a trailing semicolon. These are the lists that are re-established upon execution of a ''reset_preference'' command. | :: Establishes a default preference list for a certain group of competing rules or user methods. The syntax of the //label expression// is the same as in the interactive commands ''prefer'' and ''prefer_now'', but here you should not enclose it in quotes nor put a trailing semicolon. These are the lists that are re-established upon execution of a ''reset_preference'' command. |
| | |
| ? ''user_method'' [labels :] name ''('' [[user_guide:extend:polymorphic|signature]] '') {'' \\ ... \\ ''}'' | ? ''user_method'' [labels :] name ''('' [[user_guide:extend:polymorphic|signature]] '') {'' \\ ... \\ ''}'' |
| :: defines a method to be called from scripts and interactive shell. It should be accompanied by a properly formatted comment block. The syntax rules for the signature and overload resolution rules are the same as for user_functions, apart from the fact that the leading argument, a reference to an object of the current type, may not appear in the signature. As the name //method// says, it is inherited by all derived object types. Methods defined in derived classes completely override inherited methods of the same name only if they possess compatible signatures (that is, accept the same or broader sets of arguments than the inherited instance). | :: defines a method to be called from scripts and interactive shell. It should be accompanied by a properly formatted comment block. The syntax rules for the signature and overload resolution rules are the same as for user_functions, apart from the fact that the leading argument, a reference to an object of the current type, may not appear in the signature. As the name //method// says, it is inherited by all derived object types. Methods defined in derived classes completely override inherited methods of the same name only if they possess compatible signatures (that is, accept the same or broader sets of arguments than the inherited instance). |
| .. //labels// can be used in [[:general#preferences|preference]] settings controlling the favorites among several overloaded instances with equivalent signatures. The first limb of each label must be defined earlier in this application, or in a //used// or //imported// one. | .. //labels// can be used in [[:user_guide:howto:shell_custom#preferences|preference]] settings controlling the favorites among several overloaded instances with equivalent signatures. The first limb of each label must be defined earlier in this application, or in a //used// or //imported// one. |
| .. If the routine is declared as ''method'' instead of ''user_method'', it does not appear in the interactive help, TAB completion, or auto-generated documentation, but in all other aspects both flavors behave identically. | .. If the routine is declared as ''method'' instead of ''user_method'', it does not appear in the interactive help, TAB completion, or auto-generated documentation, but in all other aspects both flavors behave identically. |
| ? ''user_method'' [labels :] name ''('' [[user_guide:extend:polymorphic|signature]] '') : '' property, ... '' {'' \\ ... \\ ''}'' | ? ''user_method'' [labels :] name ''('' [[user_guide:extend:polymorphic|signature]] '') : '' property, ... '' {'' \\ ... \\ ''}'' |
| |
| There is also one sort of definition elements which is specific for packages not belonging to the "big" object hierarchy: so called //global methods//. They are defined exactly the same way as polymorphic user_methods, just using the keyword ''global_method''. The main difference lies in the [[user_guide:extend:polymorphic#labels|overload resolution]]: it usually takes place before the object of the class is created. The global methods from different classes having an identical signature are bundled together by preference lists and the current favorite is used to determine the class to create the object which is then passed to the chosen method. This is how all the visualization methods work. If, for example, you are going to draw a graph, all known global methods having signatures compatible to ''draw(Visual::Graph)'' are ordered according to the active preference settings, then the definition package of the method in the "pole position" determines which visualization back-end object is to be created, and finally the ''draw'' method is called with this object and the graph. | There is also one sort of definition elements which is specific for packages not belonging to the "big" object hierarchy: so called //global methods//. They are defined exactly the same way as polymorphic user_methods, just using the keyword ''global_method''. The main difference lies in the [[user_guide:extend:polymorphic#labels|overload resolution]]: it usually takes place before the object of the class is created. The global methods from different classes having an identical signature are bundled together by preference lists and the current favorite is used to determine the class to create the object which is then passed to the chosen method. This is how all the visualization methods work. If, for example, you are going to draw a graph, all known global methods having signatures compatible to ''draw(Visual::Graph)'' are ordered according to the active preference settings, then the definition package of the method in the "pole position" determines which visualization back-end object is to be created, and finally the ''draw'' method is called with this object and the graph. |
| | |