[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
|