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

[Florian Klaempfl]

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...
>
>unit whatever;
>
>{$pureint+}
>
>interface
>
>uses x, y, z;
>
>type
>   TSomeEnumType = (set1, set2, set3, set4);
>
>type
>   TMyClass = class
>     {...}
>     function SomeFunction(x: TSomeEnumType): string;
>     function SomeFunction2: TSomeEnumType;
>     procedure SomeProcedure(x: TSomeEnumType);
>     property X: TSomeEnumType read getX write setX;
>     {...}
>   end;
>
>end.
>
>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, 
>but
>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.