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.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
