What to do next?

Generally speaking, GOOL can be extended in multiple manners:

• Extend the code recognition of the currently supported input language (Java,C++).
• Extend the code generation of the currently supported output languages (Java, C#, C++, Objective C, Python).
• Extend the support for libraries (Dynamic class loading...).
• Add input languages ( C#, Objective C, PHP, ...).
• Add output languages (Javascript, GO Lang, PHP, ...).
• Only if needed: extend the GOOL intermediate language which is the bridge between all these.
• Perform the recognition of the currently supported input language (C++), Todos are comments in the code explaining the bugs to be fixed.

Still, here are some suggestions of what could be done.

Extend code generation of the currently supported input language

• Case construct, Conditional expression...
• Instance of...
• Empty statement, Break, Continue, Do while, ...

(See recognizer.java.)

Extend code generation of the currently supported output languages

C++

• Libraries: Deal with I/O (From scratch)
• Core: Fix exceptions (Currently, there is a syntax error in the generation of catch blocks: the declaration of the exception catched is wrong)

Android

• Libraries: Deal with I/O (From scratch)
• Core: Deal with exceptions(From scratch)

Objective C

• Libraries: Deal with I/O (From scratch)
• Core: Fix encapsulation of built-in type variables with object types in the code generation (Currently, the declaration of an integer is genered as int x in the output code. It should be NSInteger x.)
• Core: Fix foreach loops (This problem is a consequence of the previous one. As Integer objects are not properly generated, they currently cannot be used as loop index.)
• Core: Deal with exceptions (From scratch)

More input languages

• C#, Objective C (here is some parser).
• PHP (here is some parser).

More output languages

• Javascript, GO lang, ...

Add GOOL libraries and code generation for them:

• Dealing with Networks.
• Dynamic class loading (particularly challenging in C++).
• Forking processes and other concurrency functionalities.

This can be done in two ways (See How does it work?, Libraries support, the second is preferred when it is enough).

Transversal tasks

• Print error messages through a logger class (allowing different debug levels and co, only partially done for now).
• Try to indent the output code whenever possible.
• Chase TODOs in the code.
• The GOOL library manager is explained in How does it work?, Libraries support and The library manager. Suggested improvements:
• A more flexible and powerful syntax of the MethodMatching tables 2.3 & 3.3, allowing to reorder parameters, suppress them, put constants instead e.g. goolmethod(y,cst) -> targetmethod(y,x).
• A slightly more powerful syntax of the ImportMatching table 2.1. This table tells which imports will be intercepted by the library manager, by loading the corresponding entries in the 2.2 and 2.3 tables. But since these tables are at final package levels, table 2.1 could be of the form gool final packages <- imports e.g. goolxxx.io.* <- java.io.*, more in the spirit of a package to package correspondence.
• Handle library attribute access without methods.
• Avoid the redundant java.io.*, java.io.File in the syntax of 2.1.
• Parse methods and attributes of GOOL library classes in the GoolLibraryClassBuilder.