[fpc-devel]Export/import methods: possible?

Nikolai Zhubr s001 at hotbox.ru
Mon Nov 10 22:46:10 CET 2003

Monday, 10 November, 2003, 22:26:48, Peter Vreman wrote:
>> Hi!
>> Just before fpc 2.0 is out, I'd like to ask if it would really be
>> hard to allow to import/export methods (including constructors
>> and destructors) like plain functions/procedures, e.x.:
>> ...
>>  exports TMyClass.Work name 'TMyClass_Work';
>> ...
>>  procedure TMyClass.Work; external 'mylib' name 'TMyClass_Work';
>> ...
>> The reason I ask is because (I think) this would give some
>> (not elegant, but at least some) way to put class(es) implementation
>> into a shared lib.

> This hack will not be added to the compiler. When support for classes in
> shared libraries is needed then it needs to be fixed correctly. When you
> add hacks to a program to support something it'll face you again in the
> future and will only give more trouble.

Surely you are right that a consistent solution is always
better. However, it was mentioned somewhere that package
system is not yet planned for the nearest future.
Meanwhile, as PIC generation support is already implemented
it would seem reasonable to make more use of it, but being
restricted to plain procedural interface diminishes much
of the pleasure.
I understand that what I suggest may cause problems if
misused, but I just thought it would allow to design libraries
in a way suitable for turning into packages in the future and
not too hard to add to the compiler. Anyway, existing
(procedural) import/export can not automatically guarantee
proper use either. For example, one might incidentally declare
different number of arguments in export declaration and actual
implementation, so seems no big loss here.
Ok, don't take this all as critics :) I'm really impressed with
your excellent work.
Best regards,
 Nikolai Zhubr

More information about the fpc-devel mailing list