On Sun, May 3, 2009 at 5:44 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Mariano Martinez Peck wrote:
>
>> Andreas: Thanks for the replies. I did all of what you told me but I got
>> this error when trying to call the api:
>>
>> 'External library is invalid'
>>
>
> I think this means the name is wrong. Try using #forceLoading before you
> call any functions - this will help you to find out whether there is
> anything wrong with the name.
>
>  I even try to execute: ExternalLibrary initialize.
>>
>> However, I am not convinced why this way is better than having module:
>> aString.
>>
>
> It's not. That's why the alternatives exists. But if you have to provide a
> more flexible way of deciding which library to use there is really not much
> of an alternative.
>
>  Disadvantages of this new way:
>>
>> - I am "coupling" or "hardcoding" not only the library name but also the
>> location in the file system. Perhaps I rather this be automatically done by
>> FFI.
>>
>
> The FFI does some of this (using the default system search paths etc) and
> to the extent the FFI does it, you can use it from ExternalLibrary. In other
> words, you don't *have to* provide a full path, but you can.
>
>  Advantages of this new way:
>>
>> - I can add as many names or paths as I want to my library.
>>
>> what do you think? can you help me with the advantages and disadvantages
>> from both alternatives?
>>
>
> The rule of thumb should be that unless you have to switch between library
> names dynamically, you should be using the simple module: modifier in FFI
> calls. Only if this isn't sufficient for specifying the name you should be
> thinking about ExternalLibrary.


Ok. Now I get it. I think that in my situation is better to have module:
aString.

Thanks for the comments!

Mariano


>
>
> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090503/a204141c/attachment.htm