[Lazarus] Strange dependency of units

[Martin]

On 01/04/2012 14:15, Jürgen Hestermann wrote:
> Mattias Gaertner schrieb:
> >> 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.
> >
> > A console application is for simple stdin/stdout programs that runs in
> > the DOS box, the OS X terminal, the Linux shell, etc.
>
> Exactly. That's what I wanted to create. I only included my general 
> purpose unit which I also use for LCL programs. Some functions exist 
> in this unit that operate on TStringGrid type (but I did not use them 
> in my console program) so I had to add GRIDS to the uses clause of 
> this unit. The astonishing thing now is, that my (console) program 
> only compiles when I add the interfaces unit to the program although I 
> never actively used it.

I think, this means looking at 2 issues.

1) using grids, but without any platform/GUI dependency
2) why the need to add interfaces by hand

1)
the unit grids contains stuff, that is platform/GUI dependent.

Actually the basic concept of a unit is use it all or nothing. So by 
using Grids, you should expect all the platform/GUI dependent stuff to 
end up in your application.
  (which means a need for interfaces => leading to issue 2, why isn't it 
included/used by grids)

Sure you only refer (and only want to use) some parts of Grids, which 
would not require that. And you use smart linking, and smart linking 
usually works well.
But smart linking is an addition, an extra on top of the concept of 
units (the all unit or nothing concept).

And there are cases where smart-linking does not work. And you 
encountered one. Some of the methods, of some classes in Grids can not 
be smart linked (IIRC virtual/overridden class methods, maybe all 
virtual/overridden).
So they end up in your console app.

In other words: Using the unit Grids, even with smart linking, makes 
your app platform/GUI dependent. (even though this parts of the code 
will not be called)
For this cases the "NoGui" widgetset exists. It provides (or should 
provide) empty methods for this.


2)
The design decision not to use interfaces in Grid was done long ago.
(Thinks were different then, one think led to another...)

In theory that could be changed (like a lot of thinks *could* be done). 
In practise this may never happen (if only due to time available...). A 
re-design that big could have a lot of other side effects (which 
probably could all be remedied). But the cost might just be to high. 
(Yet I guess, if someone wants to step forward....)
I haven't looked into details, so I can't say more about it.

Originally a default implementation (a class wit abstract methods) did 
exist, so using grids, without interfaces would compile.
- If the code was not called: good
- If by some chance it was called (even totally unexpected): crash

The problem: this old implementation was very bad to smart linking. It 
caused a real lot of other unused stuff go into every exe.
In order to make it more smart-linkable (refers to a location different 
from answer "1") the abstract method declarations had to be dropped.
- Benefit: *IF* it compiles, it wont crash by calling an abstract method
- Disadvantage: In some (IMHO rare (yet still valid)) cases: you have to 
know, that you have to add interfaces.