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