Tonto | ||
---|---|---|
<< Previous | Next >> |
The first step in writing a module for TONTO is to decide whether you really need to do that.
TONTO is organised around about thirty data objects. Writing a whole module is a fairly serious undertaking in which you are required to define what data the object is supposed to store, and what operations might be performed on this data.
Initially, you might only want to add particular functionality or routine to an existing module.
If you really do want to write a whole module, or slash TONTO to bits for your own project, this chapter gives you the required procedure for constructing or deconstructing a module.
A particular style has been adopted within TONTO. This is not just for aesthetics. We believe that adhering to such a style will make it relatively easy to port foo code to other languages. Hopefully this will not be a neccesity, but writing code which has a multilingual character can only help in its maintainence and understandability.
First, you must decide what the module is supposed to do. But this does not define a module in TONTO.
Instead, a module is defined by the data which is required to do the task.
Many people, especially Fortran programmers, come from a top-down design philosophy. In this philosophy a desired task is broken into smaller bits, which are eventually coded as separate routines. This philosophy must be resisted.
For example, a common task in quantum chemistry is the requirement for "integrals". A typical Fortran programmer would write code for the formulas required, breaking the code up into routines to save repetitive coding. At the last stage, the programmer would write input routines, or provide subroutine arguments, so the user could provide the data required to evaluate the formulas. The final result would be a Fortran routine like this
call evaluate_integrals(result,input_data_1,input_data_2, ....) |
By contrast, in an object-based design philosophy, you would start by asking what data is required for the integrals. If you are using gaussian functions, that data might be the information required to define these gaussian functions. All this data would be used to define a gaussian data type. Routines and functionality would be provided so that the user could introduce this data using I/O, or perhaps from other data types. The ability to evaluate_integrals would only be one of many tasks that could be performed on the guassian. The final result in TONTO would be some lines like this
gaussian.read_data_from(stdin) gaussian.evaluate_integrals(result) |
It is the encapsulation of data and functionality together, and the set way to access a routine by its interface, which allows the object-based approach better suited for large scale programs.
Whereas in the top-down design approach the details of how a task is broken down may vary from programmer to programmer, in the object-based approach used in TONTO the data required for a task, and the functionality that can be performed on that data remains fairly universal within a specified problem context.
<< Previous | Home | Next >> |
What foo does to produce Fortran95 code | Deciding what is data and what should be a routine |