Hallo, Hans! Hello, everybody!
According to Hans Ecke:
[...]
1.) The "unit foo(bar);" part would be simple(?,IMHO): Its just that all interfaces are put after each other in order of appearence.
2.) The "inherited <someprocedure>;" part should be possible too. You have procedure-overloading.
Not yet, but we are planning to have it in gpc-2.2.
[...]
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.
No problem with this, but what about, say, a `Circle' procedure in `graph.o'? Of course, you want it to use `Communication.PutPixel' instead of `Graph.PutPixel'. This change can only be done if `graph.o' is either recompiled or calls `PutPixel' through a pointer.
Since calling functions through pointers is slower than a direct call and has other drawbacks, it is undesireable to make this the default for every unit. A more realistic approach would be to declare `PutPixel' in `Graph' as `virtual', so the compiler will make this one a pointer and assign the default value of `Graph.PutPixel' to it. Perhaps it would be desirable to have this feature built into the compiler, but (sorry if I repeat parts of my last mail):
* You can do this manually right now by declaring
Var PutPixel: Procedure ( x, y, color: Integer ) value Graph_PutPixel;
and setting `PutPixel:= Communication_PutPixel' in the initialization part of the `Communication' unit.
* You can do it by letting the unit export an object with a virtual method `PutPixel' and do all your graphics through the methods of this object (in a `with' statement). I am currently writing such a thing - it's much nicer than the "traditional" approach because you can have more than one graphics output device at the same time(-:
with Screen^ do begin ClearScreen; Line ( 0, 0, GetMaxX, GetMaxY ); end (* with *); with Printer^ do begin ClearScreen; Line ( 0, GetMaxY, GetMaxX, 0 ); end (* with *);
What I mean is: I do not see a real need for such a new feature, so it is, IMHO, not worth the effort to implement it and - perhaps even more important - not worth the problems arising from the introduction of yet more incompatibilities between GPC and other existing compilers and standard specifications.
(* But if you are interested in joining the GPC development team for doing the necessary changes to GPC, this would eliminate at least the first argument. ;*)
Schoene Gruesse,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]