Hans Ecke wrote:
[...]
unit communication(graph,keyboard,mouse);
interface
...no interface because its unchanged ...new/changed procedures or variables would be declared here
Should there be a way to "hide" some of the other units' declarations, i.e. not export all of them? If so, any ideas, how?
begin assign(logfile,`log`); rewrite(logfile);
inherited begin; (*or inherited init? or inherited main? Don't know which is better*)
I don't think this should/must/may be written at all. The initalization code of the other units will be called, anyway, before the code of this unit. I don't think there's any reason to change this, since it's good practice (also in OOP) to do the "inherited" initialization *before* one's own initialization (and the inherited finalization after one's own finalization).
BTW: Does GPC already make sure that unit initializations/finalizations happen in this order? Otherwise, this might cause problems in some programs.
New syntax-elements needed : 1.) "unit foo(bar1,bar2,..);" 2.) "inherited <someprocedure>;" Advantages are, that this new syntax is IMHO very intuitive and uses existing keywords by carefully extending their meaning.
True.
Discussion of the new syntax:
1.) The "unit foo(bar);" part would be simple(?,IMHO): Its just that all interfaces are put after each other in order of appearence.
I think (hope) so. This certainly seems useful.
2.) The "inherited <someprocedure>;" part should be possible too. You have procedure-overloading. As far as I know from C++ this is implemented by translating names of procedures :
procedure foo(s:string) -> asmname "foostring" (the identifier in the) procedure foo(i:integer) -> asmname "foointeger" (.o-file, just example)
The .gpi-file includes a mapping asmname<->pascalname of all funtions that the compiler can put a call to "foostring" for a command like foo(`bar!bar??BAR!!`) and a call to "foointeger" for foo(10).
I think, overloading of procedures for different parameters is not quite the same, but so-called "qualified identifiers" for procedures with the same name in different units are planned to be introduced until GPC 2.2, anyway.
Assuming our example, the compiler reads the line "inherited putpixel(..);". It looks for the asmname of graph.putpixel and calls it. Communication.putpixel then gets its own asmname which has to be different from the one of graph.putpixel.
Then, I agree, "inherited" procedures don't seem like a big problem.
However, there is a big difference to a "real" virtual procedure. Namely, when the original Graph unit contains a call to putpixel (e.g. from a line drawing function), the compiler can't possibly know that putpixel will be "overriden", so it will call graph.putpixel. The overriden procedure would only be effective for units using Communication. For putpixel, it might be only an efficiency problem, but e.g. mouse events that are called from within the mouse unit would not be logged in your example.
OTOH, real virtual procedures might be possible, too, but they will have to be marked as virtual in the *original* unit, and it will probably be more work to implement them. (The compiler would have to automatically generate something like the code I showed last time.)
There is the only question/problem I can see : We want to have one interface - this meens only one file communication.gpi. What with the object-files? Just leave them as (see example) graph.o,keyboard.o,mouse.o or build a librarie communication.a?
I think that's left to the programmer (when GPC will be able to produce libraries). Either he takes the several .o files, or makes a library out of them. However, there seem to be some problems (technical and syntactical) to be solved for letting GPC produce libraries.
Also a problem with the librarie : What to do with generic units which will be included often - like system.o or crt.o - include them into the librarie?
Also left to the programmer. But I would advise him not to do so, since when they will be updated, the user should have a chance to use the updated versions instead of the ones built into the library. Also, I'm not sure what happens when one uses several libraries that each include system.o.
And, please note the conditions of the LGPL under which system and crt are. If he includes their binary files, he has to provide their sources, too. Therefore, it might be easier for him, just to point to or include the complete BPCompat package.