[Lazarus] Strange dependency of units

[Hans-Peter Diettrich]

Jürgen Hestermann schrieb:

>  > Compare the compiler flags of TP and FPC. TP is a toy compared to FPC.
> 
> But what has all this to do with the concept of packages? The concepts 
> used in TP where enough to allow arbitrary complex applications. And my 
> main critic about all this is, that even when new concepts are 
> introduced they should be rock solid. This looks more like a design study.

Many languages have problems with e.g. multi-platform issues or, in case 
of Lazarus, with multiple implementations (of the widgetset), selectable 
at build time. The same for (third-party) libraries, which may or may 
not come with source code. That's why features like "packages" have been 
invented, to overcome such management problems (search paths...). Of 
course everybody can manage that himself, writing and updating Makefiles 
etc., but then he has no assistance by other tools (expect written by 
himself).


>  > The normal user creates a LCL application and everything is setup for 
> him.
> 
> That's exactly what I did. I used Larazus to create a console 
> application. I then added my general purpose unit to the uses clause. 
> Then compile failed with an error message that had nothing to do with my 
> program or unit.

IIRC your case is somewhat non-standard, because you use an *abstract* 
class. In such an case *every* user has to indicate the unit or package, 
where that abstract interface is implemented.

You are right in so far as Lazarus contains a couple of such abstract 
classes, some of which *never* can be implemented outside their 
declaring unit. Perhaps the developers *wanted* to allow for more 
flexibility, by declaring abstract classes and virtual methods first, 
but in many cases they forgot to make their supplied default 
implementation used *by default* (e.g. GRIDS), or they forgot to add 
features that allow to create alternative implementations at all (e.g. 
TDragManager).

More discussion of such issues should lead to an improved situation, 
where the inventors have fixed obvious flaws, and have added 
documentation and means for alternative implementations.

DoDi