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/10/22 17:36] – revuskydeprecated_settings [2020/11/25 12:42] – 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:
  
Line 28: Line 28:
 In general, code injection can be used to specify that any generated class should extend a given class or implement whatever interface(s). There is no need for a plethora of configuration settings for this. In general, code injection can be used to specify that any generated class should extend a given class or implement whatever interface(s). There is no need for a plethora of configuration settings for this.
  
-The following configuration options are still supported but are deprecated in JavaCC21:+The following configuration option is still supported but is deprecated in JavaCC21:
  
-  * **OUTPUT_DIRECTORY**: This is deprecated in favor of the new BASE_SRC_DIR option. See [[convention over configuration]] for more information on the preferred way to specify your directory layout when using JavaCC21. 
   * **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''. 
  
Line 41: Line 40:
 To specify the parser and lexer class names, you may use the ''PARSER_CLASS'' and ''LEXER_CLASS'' configuration options. However, it is not mandatory, since a ''Foo.javacc'' file will automatically generate a parser class called ''FooParser'' and a lexer class called ''FooLexer''. There will rarely be any practical value in overriding that. To specify the parser and lexer class names, you may use the ''PARSER_CLASS'' and ''LEXER_CLASS'' configuration options. However, it is not mandatory, since a ''Foo.javacc'' file will automatically generate a parser class called ''FooParser'' and a lexer class called ''FooLexer''. There will rarely be any practical value in overriding that.
  
-There are a host of settings that were added //after// the FreeCC fork, which was in mid-2008. See [[ancient history]] for more information on all this. No settings added to legacy JavaCC after about 2008 are currently in JavaCC 21. Most of them are of very marginal value. Moreover, it is safe to say that nobody uses them because they are not documented anywhere that I can find! Just for example, the **GRAMMAR_ENCODING** option was added at some point after 2008 (I don't know when exactly) to specify what encoding your grammar file is in. I am certain that nobody uses this. (Or just about nobody surely.) Everybody stores their grammar files in the system default encoding which is ''UTF-8'' on any remotely modern system that any serious developer would be working on. Adding these kinds of options that nobody uses is actually very typical of a [[nothingburger]] project. (Adding all these options and not even documenting them is nothingburger-ism squared!)+There are a host of settings that were added //after// the FreeCC fork, which was in mid-2008. See [[ancient history]] for more information on all this. No settings added to legacy JavaCC after about 2008 are currently supported in JavaCC 21. Most of them are of very marginal value. Moreover, it is safe to say that nobody uses them because they are not documented anywhere that I can find! Just for example, the **GRAMMAR_ENCODING** option was added at some point after 2008 (I don't know when exactly) to specify what encoding your grammar file is in. I am certain that nobody uses this. (Or just about nobody surely.) Everybody stores their grammar files in the system default encoding which is ''UTF-8'' on any remotely modern system that any serious developer would be working on. Adding these kinds of options that nobody uses is actually very typical of a [[nothingburger]] project. (Adding all these options and not even documenting them is nothingburger-ism squared!)
  
  
 See [[new settings in JavaCC 21]] for information on settings introduced in JavaCC21 that were not present in legacy JavaCC. See [[new settings in JavaCC 21]] for information on settings introduced in JavaCC21 that were not present in legacy JavaCC.