02.02.2014, 02:45, "Fred van Stappen" <fi...@hotmail.com>:
>> > Yep, thanks Michael.
>> >
>> > Hum, may i export dynamic array ?
>>
>> No, you'll need to export these as (typed) pointers and a count.
>>
>> Regards,
>> Sven
>
> Re-Aaaaargh, ok, (and i understand now why the library-examples are so simple 
> :-) ).
>
> Many thanks for that brilliant explanations.
>
> Ok, so i have to re-consider all the unit and forget the oop way and re-write 
> more procedural (Yes/No ?).

I think it should be layered. I tried to visualize the idea; take a look plz
http://s17.postimg.org/oc24gbc27/Untitled_Diagram.png
One should not write all units in procedural style to make library accessible 
from other languages. A better approach is to create API layers. For example to 
make FPC library accessible from Java and C# consider creating the following 
layers:
FPC Library core <-> FPC Library procedural layer
Procedural layer to Java OO
Procedural layer to C#
it should be like first API descends from OO level with FPC objects to 
procedural layer to make it accessible from java, then there should be java 
layer which "converts" it back from procedural flattened level to OO level with 
Java objects.

AFAIK some libraries are designed like this. 
To further generalize the idea, consider this scheme:
Language A OO <-> Language A proc. <-> dynamic lib <-> Language B proc. <-> 
Language B OO

So the point is: of course you should NOT rewrite ALL units. Create a 
procedural bridge instead and then bridges for other languages like I tried to 
explain
Of course choosing the right approach for this task it is up to you because no 
one knows your library better than you
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to