Excuse the long post - ruminations on a Sunday morning... best to read to the end, I wrote it as I went along.
At 9:41 PM +0200 29/5/04, Waldek Hebisch wrote:
Neil Santos wrote:
On 19:15 29/05/04, Waldek Hebisch wrote:
That is one of my main points in my original message.
With all due respect, I propose a different system: one wherein we could tell gpc (through maybe a command-line parameter) where it could search for the sections it needs. We could then name our interfaces and implementations the same, and just store them in different directories; maybe interface/ and implementation/ directories, or something similar.
We could then, maybe, have other parameters to fine-tune the search: something like --prepend-interface-name or --append-interface-name, and --prepend-implementation-name --append-implementation-name.
This hypothetical version of gpc could then be invoked this way:
gpc myprog.pas --automake
--module-interface-dir="./interface/" --module-implementation-dir="./implementation/" --append-interface-name="-interface" --append-implementation-name="-implementation"
Our hypothetical gpc would go compile myprog.pas, and when it encounters an import statement (say `import somemodule'), it goes into ./interface/ and looks for a file named `somemodule-interface.pas' to get the interface section, then goes to ./implementation/ and looks for a file named `somemodule-implementation.pas' to get the implementation.
I do not like to split implementations and interfaces into different subdirectiories (at least for my programs). The `--append-...' options could of course work without the `...-dir..' options. However together we get rather have machinery, and still not very flexible.
You wouldn't *have* to as you say, it'd be your choice. It might be valid in a large team effort to give some members of the team access to only the interface files and not their implementation. Which I've always thought was part of the original concept behind implementing these things anyway...
Of course, employing such a system would have to be much more robust, considering modules don't have to be named the same as the file that contains them, and that modules can export items under a different name.
My only objection is that ideally the naming scheme would be tied to the code. One thing I hate with path info, etc. is that its always one more thing that's separate from the code that needs to be remembered.
Other than that the above looks good at first glance. Have a default search rule, but make command-line options for modifying it.
Incidentally, what was Modula-2's rule (if any) on this? I swore I had a book on Modula-2, but I can't find the thing. Anyway, perhaps Modula-2 implementations had some solution to this? Or perhaps Oberon?
You can write:
import e1 in 'mod15m.pas';
to tell gpc that interface `e1' is contained in file 'mod15m.pas'. The drawback is that the "in 'mod15m.pas'" part is gpc extension, so you loose EP compatibility.
This fits what I wrote above (lucky me :-), although now there is no "rigid" way of imposed a naming rule over a whole a project other than "just remembering" each time you go to use it. Also, now the interface and implementation sections are stuck where they are: you can't move them without editing the code.
An alternative might be to refer to the current implementation and interface directories with them to be defined from the command-line, etc. e.g.
import x in '$interface-dir/y.pas' ;
If you want total flexibility then clearly you want to have a "catalog" giving correspondence interface <--> file(s). However, what I propose is very simple to implement and gives you one way to implement modular design. Also, having simple rule to get implementation file name from module name makes thing simpler for people.
Come to think of it, there is an issue if different modules (or libraries of modules) adopt different schemes and then you want to use them in one program... the import x in 'y'; has no problem, but the command-line variant does (since it fixes the one location/append rule over the build), unless you build it in several steps.
Perhaps the directory naming concept above could be extended to any number of different directories defined someplace? e.g.
import x in '$someDir/y.pas' ;
with the definition of someDir defined elsewhere.
Perhaps a small implementation file could define these things (using #defines). A common defines file could be #include'd at the head of head file. And allow the compiler to override the defines from the command-line. The file of defines can then serve as the "database" of these mappings.
Starting to sound like a certain other language that these macros come from... but I think its OK all the same ;-) Now its all defined in the code and can be edited in one place for a complete project.
s/K/C/
OK, so you meant AFAICS. Sigh. Should have guessed.
Grant