[squeak-dev] Re: [Vm-dev] Better VM <-> plugin API

Andreas Raab andreas.raab at gmx.de
Fri Nov 21 23:06:49 UTC 2008


Igor Stasenko wrote:
>> Why would it be advantageous to write:
>>
>>  static sqInt bitBlitAtom = makeAtom('ioBitBlt');
>>  registerService(bitBlitAtom, (void*) bitBlt);
>>  bitBltFn = getService(bitBlitAtom);
>>
>> instead of using
>>
>>  bitBltFn = ioLoadFunctionFrom("ioBitBlt", "BitBltPlugin");
>>
>> Is there any reason for making things even more lengthy than they are
>> already?
> 
> First, you are statically associating functionality with specific
> module ("ioBitBlt" in your example), while using atoms i don't care
> which module may set it , i care only about specific functionality.

I see. This wasn't clear in your example. What use cases do you have in 
mind? I have only once needed something like this which was during an 
interim period where we supported two BitBlt variants and I wanted to be 
able to use either one from Balloon.

Also, keep in mind that the unstructured namespace you are proposing can 
easily lead to conflicts - one of the reasons why ioLoadFunctionFrom is 
explicit about providing the plugin name is because of all of these 
"primitiveVersion" implementations out there. If you use the flat 
namespace throughout the system you'll have to have a need to 
disambiguate somehow.

> Second, with ioLoadFunctionFrom you can retrieve function, not
> arbitrary value(s).

ioLoadFunctionFrom retrieves pointers and they can of course point to 
values. For example, the Windows VM exports references to the main 
window ("stWindow") and message hooks. Check out 
<platform>/vm/sq<Plat>Exports.c for examples of platform specific exports.

> Third - you can change atom value dynamically , while
> ioLoadFunctionFrom doomed to return same value all the time - null if
> no module found or no such function in module , or function address on
> success.

Well, of course for changing values, you export functions ;-) Seems like 
the most obvious reason for exporting a function instead of a value. 
Though either way will work.

> Fourth, there are many cases where i wouldn't want to expose functions
> of my module directly (by exporting them), only indirectly.

Again, I'd be interested in knowing more about your use cases. It is 
certainly doable to do this in the VM but we should be careful about 
adding duplicate functionality.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list