Hi all!

I want to (talk) about two possibilties to enhance flexibility of Units. Since I don't know EP modules (I think the syntax is to useless complicated) the following may or may not hold for EP modules. If the following is already discussed I would be happy to recieve a pointer to the result (maybe date to search in gpclist-archive)

1.) heredity and virtuall routines for units (yes, I mean objects!) Consider the following situation : You are programming the one&only fast graphics unit. It will do graphics with direct memoryaccess (you want to program only for your very own computer). So putpixel/getpixel, bar, line will be assembler routines. To get comfort(i.e. fonts) you want to use all the routines of the graph unit (Borland, port from bpcompat). Three problems: * The outtext,circel,...-routines of the graph-unit use putpixel inside (if this is true doesn't interest now). They won't use your putpixel but the original putpixel inside graph. * A program which uses your graphics unit has to include also the original graph unit in the "uses"-clause. The program isn't interested at all in the original unit, but only in your modified one, but has to include both. The program has to deal too with changed function-definitions by justifying the order of appearance in the uses-clause. * The new unit can't change types/constants and still be able to use the old ones.

So what I would like to see would be:

/////////////////////////////////////////////////

unit graph_fast(graph);

interface

....if interface of the new unit changed, put it here

implementation

procedure putpixel(..) begin end; procedure line(...) begin end; ...

begin inherited begin; end.

////////////////////////////////////////////////// Now a unit which does nothing new, but logs each putpixel()

unit log_graph(graph_fast);

interface

implementation

var logfile:text;

procedure putpixel(x,y:integer); begin writeln(logfile,`Putpixel with parameters `,x,`,`,y); inherited putpixel(x,y); end;

begin ..assigning logfile inherited begin; end.

/////////////////////////////////////////////////// Main program

program graph_test(input,output);

uses log_graph;

....programming graphics, using fast putpixel + graph.tpu-comfort + logging facilities

end.

Maybe one could consider also Multi-heredity (is this a understandable word?) I mean something like this:

unit graph_fast(logging,graph,print);

It would be just like Multi-heredity in C++.

2.) Making Libraries from units I don't know if this task allready done. If so, ignore it. Today, units make just object files. Something like

unit1; ...Some little utility functions the user don't has to interface know about implementation end.

unit2 ...Your main unit. The user only has to work with this interface unit and even don't have to know the interface of uses unit1; unit1 implementation end.

makes 2 object files. To compile a program using unit2 you need both. If you write units for someone else (s)he will not know about unit1 (the program only knows about unit2) and maybe will delete the file. To make it more distributable we need a mechanism to concentrate all code and interface from all the forefathers of a unit (or a subset of them) into one object (or librarie) file and have the commands for it inside the source (pascal-philosophy)

I hope I was clear enough, write if not, I will correct then.

Hans