Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
From: Grant Jacobs
Subject: Module madness
Date: 30 May 2004, 12:01:08
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
Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
| Author | Subject | Date |
|---|---|---|
| Waldek Hebisch | Module madness | 29 May 2004, 21:41:29 |
Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.
Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.
This page was created by Crystal 0.999 (Linux 2.4.27/i686).