Hans Ecke wrote:

1.) heredity and virtuall routines for units (yes, I mean objects!)

I assume, you don't mean objects, but a behaviour like objects, right?

[...] So what I would like to see would be:

unit graph_fast(graph);

I understand what you mean, but I'm not sure if it's realistic to make this feature. First of all, it would severly influence the unit concept, and I'm not sure if it couldn't even break something.

Secondly, it's technically difficult. I don't know if you know about the technical details of objects (in BP or GPC), so perhaps the following might not be very meaningful to you, but anyway: a virtual method in an object is always called through a pointer which is stored in a table that every object type has (the so called VMT, virtual method table). So using virtual methods is a bit more inefficient than using normal procedures or static methods.

If you want to do the same with procedures, you'd either have to use a pointer for *every* procedure (which is not tolerable in general), or you'd have to declare "virtual procedures". Well, this seems possible to do, but consider this:

- Using such virtual procedures is (a little bit) inefficient, just like virtual methods. So, I guess, you would not want to use them in your super-fast graphics unit.

- There is already another way to do it (which does not work for object methods), namely with procedural variables:

unit graph_fast(graph);

interface

procedure this_putpixel(...) begin end;

var putpixel:procedure(...) value this_putpixel;

implementation

procedure this_putpixel(...) begin end;

...

unit log_graph(graph_fast);

interface

implementation

var logfile:text; old_putpixel:procedure(...);

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

begin old_putpixel:=putpixel; putpixel:=log_putpixel end.

Basically, it does the same as a virtual procedure would do, only you have to program it explicity. (And, of course, some initalization is necessary at runtime, which isn't necessary for virtual methods...) This means, of course, that it's as inefficient as virtual methods, there's no way around it...

- And, of course, there is always the option of making an object type out of the unit. This has the additional advantage of being able to have multiple instances (e.g. some virtual graphics screens, or remote screens on networked computers, or different windows in a window manager), but the additional disadvantage of requiring the implicit Self parameter which is again a little bit more inefficient.

E.g., I'm planning such an approach for my Crt Replacement Tool, when I ever get to write it. Of course, for Crt-like I/O, efficiency is quite irrelevant today, for graphics, it isn't...

Maybe one could consider also Multi-heredity (is this a understandable word?)

Yes, it is. The common term is "multiple inheritance", BTW.

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

Well, we have discussed multiple inheritance (for objects, of course, not for units) around May-Jun, IIRC, (easy to find in the list archive by searching for this term), and we've come to the agreement (more or less ;-) that multiple inheritance implies a lof ot problems, and that most (if not all) of its goals can be reached by something called "interfaces".

Interfaces were introduced in Java which builds on C++. Obviously, the Java inventors realized the problems inherent in multiple inheritance, and therefore invented this safer concept. With GPC, we want to take the short cut to the safe concept... :-)

Basically, interfaces contain a list of declarations of virtual methods, but no implementations or fields. An interface can inherit from multiple interfaces, and an object type can inherit from multiple interfaces, but only from one object type. Parameters of interface type, and pointers to interface types are possible.

Implementing interfaces into GPC will not be quite easy, but we have figured out most of the details by now, so there's hope that they will be realized until GPC 2.2 (no promises).

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

It has been discussed, and is planned, but AFAIK, no concrete work or consideration has been done yet.

BTW: I have set up a To-Do list for GPC at http://home.pages.de/~fjf/gpc-todo_toc.html There, you can see which features are planned, and which bugs are known (provided, you can decipher my sometimes quite crpytic entries... ;-)