Sorry for late reply, didn't noticed this mail before. On 26 November 2012 21:32, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:

Hi Igor,

While I'm waiting impatiently for the new NB version I played around some more and I have noted some ideas:

First thing is related to structures and callbacks... what if I want to have a callback as a member of a structure? It seems to me that the way to go is to declare a MyCallback class and then use it in the structure, which is fair enough. But what if I have a function that initializes this structure with a user provided callback? Then the structure is not printed correctly. It seems that #coerceReturnValue: is not implemented in the NBCallbackType... While this is not a big issue it made me think that I was doing something wrong... Maybe in this case we can instantiate MyCallback class and put the fct pointer in in trunk ivar.

A unique instance of callback has unique trunk. This is the only way to identify, which callback was called at runtime. A coerceReturnValue: is not implemented simply because callback has non-trivial initialization procedure and intimately connected with VM internals etc.. you cannot just take random pointer value and then convert it into instance of your callback.. (because this is what coerceReturnValue: should implement). As a compromise, however, coerceReturnValue: could simply answer a NBExternalAddress. so, as input value, it will require a valid callback object instance, and as return value it will give you an address. Does that sounds like a plan?

Secondly, related to structs again... It seems that we can define structures like: struct { void *a[2]; } only by transforming them to struct { void *a1; void *a2; } Am I wrong... if not maybe we can extend a little bit the syntax for defining structs to accept the first form... which will be far easier to write if we have large index values like void *x[20]... What do you think?

yes the "syntax" for struct fields is very simplistic. I put things which was easy to put.. leaving full C coverage for a future. If you want to extend it.. First we need to implement array-type values.. which i wanted to introduce since a while.. but had no time to work on it yet :)

Lastly, seeing that we are starting to have support for most of c-like declarations, i am not really satified with the way the enums should be handled... Maybe we can reify them as some kind of external object so that we can say something like: enum { AAA = 1, BBB = 2, }; MyEnum AAA (to get the item AAA of the enum) MyEnum BBB value = 2 and behind the enumeration is defined as a Dictionary of item->value mappings.

This is all good, but doing dict lookup at run time costs a lot more than just using shared pool var. Nothing prevents one from writing a code generator which converts enum {...} syntax into pool initialization method. So you could have best of two worlds (and you can even keep original sources with enum syntax somewhere, to be able to regenerate the code in case of changes)... Which brings is to the question: how often enums need changes? (Hint: almost never). So i agree, it would be cool to have enum -> pool code generator.. which can save little time. (you will use it once per writing binding to some library). As for dictionaries.. bad idea :) i am not ready to pay the price of doing dictionary lookups every time i need constant from enum.

Attached to this mail you will find a fileout of such an approach...

not today.. but i will look at it.

I agree that maybe this is not the most optimized way of dealing with enums, however I like this approach because it is uniform (with structs, external objects, external addresses, callbacks, etc). Moreover if a beginner wants to hack his way into NB FFI I think it is easier to cope with an enum object than with SharedPools defined in classes, and imported.

Cheers, PS: I can't way to get my hand on the new version...

-- Dr. Ciprian TEODOROV Ingénieur Développement CAO

tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro

-- Best regards, Igor Stasenko.