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 revision		Previous revision
Next revisionBoth sides next revision
deprecated_settings [2020/11/25 12:42] – revuskydeprecated_settings [2021/10/19 19:57] – revusky
Line 18: Line 18:
   * **CACHE_TOKENS**: I never even understood what the point of this setting was. It must have been some kind of //speculative// peephole optimization, except I don't think it was even correct. There would be problems with switches of lexical state in some cases. Also, I doubt it offered any noticeable performance gain. The setting is now gone and is always effectively false. (Which was the default before, which everybody was using anyway.)   * **CACHE_TOKENS**: I never even understood what the point of this setting was. It must have been some kind of //speculative// peephole optimization, except I don't think it was even correct. There would be problems with switches of lexical state in some cases. Also, I doubt it offered any noticeable performance gain. The setting is now gone and is always effectively false. (Which was the default before, which everybody was using anyway.)
   * **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.
 +  * **USER_DEFINED_TOKEN_MANAGER** : This setting was removed in October 2021. 
   * **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 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_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.
Line 23: Line 24:
  
 <code> <code>
-   INJECT(BaseNode) : {extends SomeClass}+   INJECT BaseNode : extends SomeClass
 </code> </code>
  
Line 31: Line 32:
  
   * **NODE_PREFIX**: Use of this is not encouraged in JavaCC21. By default, it is simply the empty string. (In JavaCC (or JJTree to be precise) it was "AST" by default.) I guess that prefixing all the Node classes with "AST" is a (crude) way of defining a Namespace. However, one would think these people noticed that Java has this thing called ''packages''.    * **NODE_PREFIX**: Use of this is not encouraged in JavaCC21. By default, it is simply the empty string. (In JavaCC (or JJTree to be precise) it was "AST" by default.) I guess that prefixing all the Node classes with "AST" is a (crude) way of defining a Namespace. However, one would think these people noticed that Java has this thing called ''packages''. 
- 
-The following option has been renamed for consistency, but the older name is still supported: 
- 
-**USER_TOKEN_MANAGER** is now **USER_DEFINED_LEXER**. 
  
 The use of both ''PARSER_BEGIN....PARSER_END'' and ''TOKEN_MGR_DECLS'' is deprecated in favor of the new [[Code Injection in JavaCC 21|code injection feature]]. Injecting code into the generated parser and lexer is simply a specific case of code injection, so there is no need for these separate constructs. However, they will continue to work for the foreseeable future. The use of both ''PARSER_BEGIN....PARSER_END'' and ''TOKEN_MGR_DECLS'' is deprecated in favor of the new [[Code Injection in JavaCC 21|code injection feature]]. Injecting code into the generated parser and lexer is simply a specific case of code injection, so there is no need for these separate constructs. However, they will continue to work for the foreseeable future.