Hi!As long as your unit order is correct this will simply work. No external needed. Forget about that.
I want a header unit that redeclares types and functions of a lot of other units so that you only have to add the header to the uses section instead of a bunch of smaller files. For types this is simple:
Is there some equivalent for procedures and functions? I only know of the external keyword but I think this is for compiled libraries (*.DLL, *.SO) only.
It might be the same question like this but the discussion confuses me a bit so I'm not sure:
https://stackoverflow.com/questions/25893908/how-to-reference-an-external-function-from-inside-a-unit
unit A;
interface
type T = byte;
implementation
end.unit B;
interface
procedure P;
implementation
procedure P;
begin
WriteLn('P');
end;
end.unit C;
interface
uses A;
// T is already available here
implementation
uses B;
// T and P are available here
end.
You can write a inline wrapper / not perfect, but compiled with optimization, it *should* be no extra code in the exe.Or use procedure type variable:
Ok for example in my game engine I have many classes which I don't want to have in one file like TMesh, TScene or TLight and a lot more.
[. . .]
and in graphics.pas I do this:
[... some code ]
And if I want to use the game engine in a project I would simply do this:
[... some code ...]
This should work perfectly unless I want to define a function/procedure in one unit (not a method).
[... some code ...]
If I include this unit in graphics I can use the ClearScreen function there. But if I want to use this procedure in "SomeGameUnit.pas", the only way I can think of is putting my function into includes instead of separate units.
There is one more way.Just for the implications: Does it mean I can only have one function of that name in the package, in the scope or for the whole executable?
In the unit where it is implemented (afaik,only implementation is needed):
In the big unit
The compiler will not match them, so you get no error, if they have different declarations. If they do not match, you get a crash when you run your app.
It is the linker, that will connect them together.
Maybe you're right but I also tend to have very small files with only a few classes and functions. I don't want to burden any user having to remember which file is in which small unit. But I suppose maybe I find a solution in between because I don't want too many "hacks" in the code.Ok for example in my game engine I have many classes which I don't want to have in one file like TMesh, TScene or TLight and a lot more.
[. . .]
and in graphics.pas I do this:
[... some code ]
And if I want to use the game engine in a project I would simply do this:
[... some code ...]
This should work perfectly unless I want to define a function/procedure in one unit (not a method).
[... some code ...]
If I include this unit in graphics I can use the ClearScreen function there. But if I want to use this procedure in "SomeGameUnit.pas", the only way I can think of is putting my function into includes instead of separate units.
What you pretend is to have all the (suppossed) advantages of one big unit without paying the (very real) cost of having one big unit: it can be done, more or less, for classes but for separate procedures/functions you have basically the solutions proposed by ASerge and Martin_fr ... but both will make you end up with a big (although smaller) unit again.
Instead of that use the power of units to the hilt. There's no need for you to use include files nor, indeed, a mega-include-all-classes graphics.pas; you can simply add your small "one-class" units to the uses clause of SomeGameUnit.pas. It also allows the IDE features to work better, since unit is, let's say, their basic building block.
Just for the implications: Does it mean I can only have one function of that name in the package, in the scope or for the whole executable?It is the alias that must be unique. And yes the alias must be unique across the entire app. I am not sure what the maximum length for the alias is (there probably is a restriction).