|
|
| Line 1: |
Line 1: |
| − | The following is very confusing to read:
| |
| | | | |
| − | If '''''variable''=''value''''' is an attribute in [variables], then the expression '''$''variable'''''
| |
| − | is a shortcut to ''value''.
| |
| − |
| |
| − | If '''[''array'']''' is a tag in [variables], then '''$''array''.''variable'''''
| |
| − | has the same value as '''$''variable''''' does in [''array''].
| |
| − | For example if [''array''] contains the attribute '''variable=value''',
| |
| − | then the expression '''$array.variable''' will be interpreted as '''value'''.
| |
| − |
| |
| − | I propose to make it a rule in WML reference not to use technical terms (''variable'', ''array'') as variable names or tag names in examples, and always to state explicitly if some term or reference is a reserved word (tagname, attribute name, name of a core macro) or if it is being used as an example. The ''foobar'' convention is valuable in such cases, as it shows implicitly which words are "reserved", and which are defined by the programmer:
| |
| − |
| |
| − | If '''''foo''=''bar''''' is an attribute in [variables], then the expression '''$''foo'''''
| |
| − | is a shortcut to ''bar''.
| |
| − |
| |
| − | If '''[''foo'']''' is a tag in [variables], then '''$''foo''.''bar'''''
| |
| − | has the same value as '''$''bar''''' does in [''foo''].
| |
| − | For example if [''foo''] contains the attribute '''bar=foobar''',
| |
| − | then the expression '''$foo.bar''' will be interpreted as '''foobar'''.
| |
| − |
| |
| − | In this example, it is now easy to see that [variables] is a standard tag, whereas [foo] is a user defined tag.
| |