Re: Relationship between IoTag and IoObject

Steve,

Thanks for answering my questions about perform and activate.

Unless I can use the perform hook to implement custom method tables (if I can that'd be swell!), I feel the issue of IoCFunctions needs more discussion:

--- In [email protected], Steve Dekorte <steve@...> wrote:
> I don't recommend this. I'd recommend creating an OO binding instead. You might check out some of the other Io addons for examples.

> Basically, you write a C function (Not a IoCFunction) for each function you want to bind

But that's just it; I do not want to write a C function for each function I want to bind.  I have written a C++ library that can automatically generate Io bindings for C++ APIs - binding hundreds of functions (attached to instances of classes) at a single go.  Because the C++ front end bindings are machine generated, it wouldn't be practical for the Io back end have to be human-generated!  But I cannot generate C functions using C++ metaprogramming techniques, hence why I pass everything through the eye of the needle of one human-written C entry point.

The requirement of a different C function for every function bound in Io is a limitation of Io's traditional way of thinking about library bindings, but it is not an inherent limitation of how things could work.  In particular it differs from how both pthreads calls functions on new threads, and how Python bindings work.

In the current design a C function called from Io has only one distinguishing piece of pointer data - its own address, which the C code knows implicitly.  This is of limited utility because you cannot put arbitrary information in this pointer, such as pointing to a C++ object instance (because of the requirement of course that the target of this pointer be executable code!!)  Since the function pointer must point to executable code, it would be useful to add a second pointer that can point to any user-defined data structure.

This isn't that uncommon of a pattern in many C APIs:  Take pthreads for instance - in addition to the C function address it will call when it starts a thread, pthreads also accepts a user-defined void* to pass to that function.  Python AFAIK also supports exactly what I'm proposing in its own binding API.  I had a lengthy discussion with David Abrahams about how Boost.Python works and he was frankly surprised Io did not already provide this facility.  He used the adjective "crippled" to describe systems which do not provide the ability to attach user-defined data to bound functions, because lack of it makes things difficult.

If, however I can hook the perform function to implement custom method lookup for my objects then Io may not be so crippled after all.  I could have easily added the second pointer to my fork of Io and gone on my merry way, but I hope to not generate incompatibilities between what I have and the mainline.  So my hope here is to either convince you that adding a user-defined call target void* to Io method tables is a good idea, or to be told there's already a way I can do it without changing the Io code.