[fpc-pascal]Interface-only units (was: shared libraries interface)
Florian.Klaempfl at gmx.de
Fri Aug 2 14:26:37 CEST 2002
At 13:06 02.08.2002 +0100, you wrote:
>Quoting Jonas Maebe <jonas at zeus.rug.ac.be>:
> > On Fri, 2 Aug 2002, Full_Name wrote:
> > > One other point.. surely the interface is there just for the
> > > convenience of the developer - like a C header file.
> > No, it's mainly to guarantee portability between different compiler
> > versions.
>But the interface is still to be thought of as 'read only' ? Otherwise, it
>would be possible to alter the interface... not good for maintenance.
>eg. consider the following...
>uses x, y, z;
> TSomeEnumType = (set1, set2, set3, set4);
> TMyClass = class
> function SomeFunction(x: TSomeEnumType): string;
> function SomeFunction2: TSomeEnumType;
> procedure SomeProcedure(x: TSomeEnumType);
> property X: TSomeEnumType read getX write setX;
>What would happen if I compiler this, gave it to people, and someone changed
>TSomeEnumType? For example to the following:
> TSomeEnumType = (setNone, set1, set2, set3, set4, set5, set6);
>If I had written code internally well, hopefully not too much would break,
>I still think this is dangerous. This is one reason why the DCU/TPU concept
>arrived in the first place.
Of course, but see my other mail which decribes the problems with the indizies
and this problem comes from the binary DCU/TPU concept. While the pureint
concept would allow to recompile the interface and everything would be fine.
More information about the fpc-pascal