meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
deprecated_settings [2020/10/22 17:36] – revuskydeprecated_settings [2020/10/22 17:37] – revusky
Line 19: Line 19:
   * **TRACK_TOKENS** : There is no real reason for this setting to exist any more, since, by default, Tokens are added to the AST and they have their line/column information. In fact, all Node objects have line/column information.   * **TRACK_TOKENS** : There is no real reason for this setting to exist any more, since, by default, Tokens are added to the AST and they have their line/column information. In fact, all Node objects have line/column information.
   * **COMMON_TOKEN_ACTION** : This feature is still supported but the configuration setting is no longer necessary, since JavaCC21 deduces it from the presence (or absence) of the appropriately named method in your generated lexer class. If you have a method with the signature ''void CommonTokenAction(Token t)'' it will be called at the appropriate point. However, you would be better off using the newer alternative, which you use by creating a method with the signature ''Token TOKEN_HOOK(Token t)''. It is more flexible because, for one thing, it allows you to define multiple token hook routines. See [[https://javacc.com/2020/10/16/token-hooks-revisited/ | here]] for more information. Also, since this method has a return value, it allows you to instantiate a new Token object (of whatever subclass) and return it. In any case, there is no need for the configuration setting, since these methods are used if present and if not, not. (//Duh!//)   * **COMMON_TOKEN_ACTION** : This feature is still supported but the configuration setting is no longer necessary, since JavaCC21 deduces it from the presence (or absence) of the appropriately named method in your generated lexer class. If you have a method with the signature ''void CommonTokenAction(Token t)'' it will be called at the appropriate point. However, you would be better off using the newer alternative, which you use by creating a method with the signature ''Token TOKEN_HOOK(Token t)''. It is more flexible because, for one thing, it allows you to define multiple token hook routines. See [[https://javacc.com/2020/10/16/token-hooks-revisited/ | here]] for more information. Also, since this method has a return value, it allows you to instantiate a new Token object (of whatever subclass) and return it. In any case, there is no need for the configuration setting, since these methods are used if present and if not, not. (//Duh!//)
-  * **NODE_SCOPE_HOOK** : As with COMMON_TOKEN_OPTION, the feature is still supported but the configuration option is no longer necessary, since JavaCC21 deduces it from the presence or absence of the appropriately named method or methods in your generated parser class. See [[Node Life Cycle Hooks]] for more information.+  * **NODE_SCOPE_HOOK** : As with the ''COMMON_TOKEN_OPTION'', the feature is still supported but the configuration option is no longer necessary, since JavaCC21 deduces it from the presence or absence of the appropriately named method or methods in your generated parser class. See [[Node Life Cycle Hooks]] for more information.
   * **NODE_EXTENDS** : Since JavaCC21 has ''INJECT'', there is no need for this configuration option to exist. If you want to specify that your BaseNode class extends some specific class, simply use [[Code Injection in JavaCC 21|code injection]] to specify this. Something like:   * **NODE_EXTENDS** : Since JavaCC21 has ''INJECT'', there is no need for this configuration option to exist. If you want to specify that your BaseNode class extends some specific class, simply use [[Code Injection in JavaCC 21|code injection]] to specify this. Something like: