Previous Up Next

Chapter 9  Other Programming Languages

9.1  Introduction

I hope that, over time, people will volunteer to implement Config4* for numerous programming languages. If that happens, then there will be several important benefits.

First, no matter what programming language a person decides to use for an application, there is a good chance that he or she can use Config4* rather than having to use an inferior configuration technology.

Second, it is common for different parts of a large project to be implemented in different languages. For example, in a client-server system, server applications might be implemented in C++, client applications in Java, and administration utilities in Perl. Since those applications are all part of the same overall project, there is a good chance that they will all need the ability to parse a common configuration file.

Third, the "uid-" prefix promotes Config4* from being “merely” a configuration language to being a file format suitable for data exchange. Having implementations of Config4* in many programming languages will make it possible for a program implemented in one language to exchange data with programs implemented in other languages.

This chapter summarises some of the issues that are likely to arise in implementing Config4* in a wide variety of programming languages.

9.2  Scripting Languages

Let’s assume an implementation of Config4* requires about 10,000 lines of code (excluding comments and blank lines). What’s a good way to implement Config4* for popular scripting languages, such as Lua, Perl, PHP, Python, Ruby and Tcl?

One way is to write 10,000 lines of Lua code to implement Config4Lua, then write another 10,000 lines of code to implement Config4Perl, and so on. However, this approach suffers from two problems. First, many scripting languages are interpreted, so Config4* implemented directly in a scripting language will be relatively slow. Second, 10,000 lines of code in each of several scripting languages quickly adds up to be a lot of code to write and maintain.

A better way is based on the fact that many popular scripting languages (including those mentioned at the start of this section) are implemented in C and can be extended with new functionality written in C. Thus, a good first step would be to write 10,000 lines of C code to implement Config4C. Then, a few hundred lines of extra code could be written to provide a Lua extension “wrapper” around the Config4C library, another few hundred lines of code could be written to provide a Perl extension “wrapper” around the Config4C library, and so on. This approach would provide a compiled—and hence fast—implementation of Config4* for scripting languages. It would also significantly reduce the amount of code, and hence effort, required to add Config4* to scripting languages.

9.3  Advice for Implementers

If you want to implement Config4* for another programming language, then I suggest you take the following steps.

Start by reading all the Config4* documentation. In particular, make sure you understand the information in this manual (the Config4* Maintenance Guide).

Then make a copy of the source code of Config4Cpp or Config4J, and start hacking at the copy to translate its syntax into that of your target programming language. Doing this translation will be tedious—I know this, because I used this approach to develop Config4J from Config4Cpp—but it offers two benefits. First, it will help to familiarise you with the architecture and source code of Config4*. Second, this translation approach is much faster than developing a new implementation of Config4* from scratch.

Previous Up Next