Repository navigation
Libraries support
The GOOL library manager is the new, preferred solution for the ''soft-coded'' recognition and generation of libraries (classes and their method calls). It uses a few ''container'' GOOL Abstract Syntax Tree nodes to represent all the classes and method calls that have been implemented with this solution. A collection of configuration files is used to :
- define abstract GOOL classes (which are organized in packages) and their methods
- match them with concrete classes / methods in the input language
- match them with concrete classes / methods in the output language, or implementations in the output language.
Just by filling these configuration files, the ''container'' GOOL Abstract Syntax Tree nodes becomes able to represent more libraries, to match them with input languages libraries, and to generate the appropriate code in output languages, through matching or implementation. Thus, the no longer needs to have an accurate knowledge of the inner workings of the GOOL system. Moreover, the solution is more modular, as it respects the core versus libraries duality.
All these files are located into the gool/classdeclarations directory.
There is one class declaration file for each abstract GOOL class. Its name is the name of the class. GOOL classes are organized in packages. For example, the declaration of the GOOL class io.GoolFile is located in the file gool/classdeclarations/io/GoolFile.
These files contain 4 types of declarations :
- Field declarations :
Syntax: [field] <name> : <GoolType>
where <name> is the field name and <GoolType> is either the full name (e.g. io.GoolFile) of a GOOL class, or a type implemented in the gool.ast.type package (e.g. GoolString).
- Constructor declarations :
Syntax: [constructor] <GoolClassName> ( <list of comma-separated GoolTypes> )
where <GoolClassName> is the short name (e.g. GoolFile) of the current GOOL class and <list of comma-separated GoolTypes> a list of parameters types as above.
- Method declarations :
Syntax: [method] <methodname> ( <list of comma-separated GoolTypes> ) : <return GoolType>
where <methodname> is the name of the method (e.g. createNewFile), <list of comma-separated GoolTypes> a list similar to those in the constructor declarations, and <return GoolType> a type as above.
- GOOL class dependency declarations :
Syntax: [dependency] <GoolClassName>
where <GoolClassName> is the full name of a GOOL class (e.g. io.GoolFile) that is required by the current GOOL class to work. For example, io.GoolBufferedReader needs the GOOL class io.GoolFileReader for its implementation to work in the target language. That is why io.GoolFileReader is a dependency of io.GoolBufferedReader.
All of these files are located into the gool/recognizer/xxx/matching directory, where xxx is some input language.
There is just one of these files for each input language.
The file, named ImportMatching.properties is located at the root: gool/recognizer/xxx/matching.
Each line of this file matches a GOOL class name on the left hand side, with one or several imports from the input language on the right hand side.
Syntax: <GoolClassName> <- <comma-separated list of input language imports>
where <GoolClassName> is the full name of a GOOL class (e.g., io.GoolFile) and <comma-separated list of input language imports> a list of imports (e.g. java.io.File, java.io.*).
If one import of the right hand side appears in the input program, then the recognition of the corresponding GOOL class and its methods will be activated.
There is one of these files per input language and GOOL final package (i.e., that does not contain any other GOOL package).
Each file, named ClassMatching.properties must be located in the subdirectory of gool/recognizer/xxx/matching corresponding to the GOOL final package of the GOOL classes that is matches.
Each line of this file contains matches a GOOL class on the left hand side, with one or several concrete input language classes on the right hand side.
Syntax: <GoolClassName> <- <comma-separated list of input language classes>
where <GoolClassName> is the full name of a GOOL class (e.g., io.GoolFile) and <comma-separated list of input language classes> a list of full names of concrete classes in the input language (e.g. java.io.File).
If an expression typed with one of the class of the right hand side appears in the input program, then it will be recognized as the corresponding GOOL class in the abstract GOOL language.
There are one of these next to each « input class matching » file. Each line of this file contains a match with a GOOL abstract method on the left side, and one signature of a concrete method in the input language on the right side.
All of these files are located in the gool/generator/yyy/matching directory, where yyy is an output language.
There is one of these files per output language and GOOL class. Its name is <GoolClassName>.imports where <GoolClassName> is the short name of the GOOL class (e.g., GoolFile) and is located at the root of the GOOL final package. (i.e., gool/generator/yyy/matching/io for GoolFile.imports.
These files contain the raw code in the output language that imports the libraries that are required to make the implementation of the GOOL class work. The content of this file is then added as a header in the GOOL class implementation output file.
There is one of these files per output language and GOOL final package (i.e., that does not contain any other GOOL package). Its name is ClassMatching.properties and is located in the subdirectory of gool/generator/yyy/matching corresponding to the GOOL final package of the GOOL classes that it matches.
Each line of this file contains a match with a GOOL class on the left side, and a concrete class in the output language on the right hand side.
Syntax: <GoolClassName> -> <concrete output language class>
where <GoolClassName> is the full name of a GOOL class (e.g. io.GoolFile) and <concrete output language class> a concrete class in the output language (e.g. java.io.File or just File depending on whether java.io is in the imports of the class).
When generating the code of an expression typed with a GOOL class on the left hand side, the actual textual type of the expression in the output language code will be the corresponding output class name.
The keyword noprint can also be used as an output language class if there is no concrete implementation for this class.
There is one of these per output language and GOOL method/constructor. Their name is the signature of the GOOL method declared in the GOOL class definition file (with no separator). They are located in the subdirectory corresponding to the GOOL class they belong For example, the GOOL class io.GoolFile has a GOOL method with the signature createNewFile():TypeBool. The Java implementation of this method is located within the directory gool/generator/yyy/matching/io/GoolFile, and more precisely into a file named createNewFile():TypeBool.
These files contain raw code in the output language that implements a GOOL method. The content of this file is then added as a method definition in the GOOL class implementation output file. If the file is empty or cannot be opened, its implementation in the output source code will be replaced by a commentary notifying that it has not been implemented yet for the given output language.
io.GoolFile : A class used to represent a file or a directory, it's similar to java.io.File .
io.GoolFileReader : A class for reading character files, it's similar to java.io.FileReader .
io.GoolFileWriter : A class for writing character files, it's similar to java.io.FileWriter .
io.GoolBufferedReader : A file reader class using a character buffer, it's similar to java.io.BufferedReader .
io.GoolBufferedWriter : A file writer class using a character buffer, it's similar to java.io.BufferedWriter .