[Lazarus] Identifier not found, but code completion works....

[Mattias Gaertner]

On Sat, 19 Feb 2011 15:11:13 +0100
Bo Berglund <bo.berglund at gmail.com> wrote:

>[...]
> >> >[...]
> >> > When I did this lazarus showed me hints on what I could select when I
> >> > added the period after the serComm name, so I know that it is known by
> >> > lazarus.
> >> > But when I try to run the program lazarus shows an error:
> >> > 
> >> > unit1.pas(22,21) Error: Identifier not found "TSerial"
> >
> >I just got the same error.

... with another unit and identifier.

> >The cause was a cross unit reference. Implementation uses sections are
> >evil. It's near impossible to create simple bug reports for such
> >compiler bugs.
> >
> Could you expand on this?
> 
> I am used to my Delphi practice of putting uses references as far down
> the ladder as possible.
> This means that if something is not needed in the interface section I
> routinely put it into the implementation uses.
> 
> Is this bad practice with FPC/Lazarus?

The general idea is a good one, because this could help to avoid
unneeded/accidental dependencies in the interface.
OTOH I never got that case in reality, so I wonder if this really
helps someone.
For the program size or unit dependencies it does not
matter if the unit is used in the implementation or the interface.
The implementation uses section has some disadvantages:
1. It can redefine types. For example using the Windows unit redefines
TRect.
2. You can create "circular" dependencies without noticing.
2.1 Circular dependencies make it hard to tell the order of
initialization sections.
2.2 Combined with some optimization features the compiler
has to recompile some units multiple times. Since I know FPC this
process had bugs, resulting in strange errors. The FPC team did a
great job to fix all they could reproduce. The problem is that the
remaining bugs happen only in big programs and it is near
impossible to create a small example, so these bugs are not reported
and therefore not fixed.
2.3 Circular dependencies make refactoring a lot harder.
3. The uses section is split, reducing readability.

Conclusion: I don't see any real advantage but I see some
disadvantages, so I recommend to avoid the implementation uses section
whenever possible.


Mattias