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