Why does CodeWorker have been developed?The adventure of CodeWorker started in 1996, with the wish of avoiding typing some repeatitive and tedious programming tasks. It is better to focus the skills of a developer on modeling and implementing code once, rather than writing kilometers of code lines. How to reach these points, to grant these wishes? Not by proposing a new method that doesn't offer something concrete, but just reassures the staff and puts back the problem further. So, you'll never heard me to tell you: "It concerns the development's team, we don't care about the final implementation tasks, except that you must conform to the method 'XXX' and all will be OK! Now, give me money!". But I can do it, if you insist.
So, not a method to propose, but a software that does the work properly. The first step is to allow acquiring data (UML, source code, personal description...), stored in any kind of text files (Rational ROSE, JAVA, HTML, DTD, personal format...). The second step is to organize the interesting parsed information into structured types, which hold the role of a parse tree. The third step is to generate code (any kind of text) or to transform existing files, according to the parsed data.
Why use an adapted language for doing the job?At the beginning, the intention wasn't to implement a new language, but to extend a generalist language with specific components for parsing text and generating code. The library was written in C++, and offered some convenient functions for reading tokens and for extracting protected areas from a file, for example.
However, text to generate was written in the syntax of C++, using stream operators (once the pattern to generate code has been written, it is too hard to move or change some parts), and data structures were declared in C++, heavy to manipulate (quite verbose to iterate a list in C++, not flexibility enough to change structures if some attributes or associations have to be added or moved or changed, ...). This approach was acceptable on projects where the data to extract weren't too complex, and were the source code generation was quite simple. But it is unusable on big source code generation projects and hard on complex data structures.
If you share the same experience, you know that it is just sufficient to convince you that a fascinating world may be tackling with source code generation, but that the syntax of a generalist language doesn't allow to do more than touching upon this world. So, a new language had to be implemented, mainly (at this time) to make easier the source code generation in a way that is very common today: by inlaying the scripting language to interpret into the text to write. This is exploited for instance by:
Why not to exploit an existing scripting language?This new language was an interpreted scripting language, where parsing, data representation and source code generation could be developed and manipulated in an homogeneous way (all in the same language), and where the syntax could be adapted to facilitate as well source code generation than parsing or data handling. And now, we dispose of:
CodeWorker is maintained by Cedric Lemaire.
Please send a mail to Submit a bug or feature