[fpc-pascal]Interface-only units (was: shared libraries interface)

[Florian Klaempfl]

At 15:15 02.08.2002 +0200, you wrote:
> > >I don't see the use of such a construct:
> > >A. If the internal naming conventions of the compiler change,
> > >    chances are that the object file is useless anyway.
> > >B. If the internal alignment rules for constants, sets, records and
> > >    I don't know what change, then you're stuck as well.
> >
> > If the system unit gets a new type/var/proc/...or even if you
> > reorder the source code of the system unit the indizies for
> > some system unit ppu entries change => ppus compiled with older systems
> > unit doesn't work anymore though neiter A. nor B. apply :)
>
>So you're only my case stronger =-)

No, with pureintf it would work without any problems ...

> > >So I see no real use for a 'interface-only' unit.
> > >What is more, you can easily make o an 'interface-only unit' now. The
> > >easy way is to have all functions in a separate object file and create
> > >a unit that just contains the needed definitions.
> > >This is already possible as follows:
> >
> > But it doesn't work flawless with objects and classes etc. I think
> > and you've to maintain to sets of interfaces or you've to use
> > lot of ifdefs...
>
>But the same is true for interface-only units, so you're in trouble
>in any case...
>
>My conclusion is that interface-only units are useless, and not worth
>the effort.

No they aren't :). Consider a large library which is closed source (most
of us don't like it, but they exist.) Even if we added only one entry
to the system, this packages isn't usable anymore with 1.0.6 if it
was compiled with 1.0.6. With the pureintf stuff it would be still
usable because neither A. nor B. did happen between 1.0.4 and 1.0.6 :)