Hi, 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 _______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
