Re: Re: Relationship between IoTag and IoObject

On 2011-06-13 Mon, at 10:49 PM, dennisf486 wrote:
> 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!),

Yes, you can. I suggest looking at the CFFI binding.

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

There's no such requirement. That's just the common pattern because it makes the most sense in most situations. For example, if you want to be sure your binding is type safe (the user can't crash the program via it). All CFFI's are inherently broken because neither C or C++ contain enough meta info for *any* automatic binding mechanism to know how and when to properly alloc, dealloc, or initialize structs or what requirements and expectations functions have wrt the pointers and structs passed to or returned from them. e.g. who owns the memory to a pointer to a struct passed? How should it be initialized? What are the semantics of NULL? What are the error semantics? Who owns the memory returned? etc. C/C++ (sadly) don't tell you so all that info must be hand coded and these are the types of uses custom binding functions deal with.

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

I'm not sure what you mean - you can put whatever you like inside an IoObject's data pointer struct (and an IoCFunction is just another type of IoObject like every other atom in Io). Unlike other languages, Io is just a message sending machine. When you create a custom atom, it works on exactly the same level that all the Io atoms work at - you have essentially added new instructions and types to the "VM". 

- Stvee