Re: [xmlvm-dev] Generating Java iOS API

[Aaron V. <gru...@gm...>]

Do you think it could work simply to use List<SomeType> where
SomeType[] is used in C, and Reference<SomeType> where SomeType* is
used?  Even though C compiles them identically, we can still
distinguish the intent in the header files.

On Mon, Oct 10, 2011 at 4:32 AM, Panayotis Katsaloulis
<pan...@pa...> wrote:
>> ----------------------------------
>> CGFont.java:
>>       /**
>>        * bool CGFontGetGlyphBBoxes(CGFontRef font, const CGGlyph glyphs[],
>> size_t count, CGRect bboxes[]) ;
>>        */
>>       public boolean getGlyphBBoxes(short[] glyphs, int count,
>> Reference<CGRect> bboxes)
>>
>> The mapping from CGRect[] to Reference<CGRect> at first glance didn't
>> seem correct, but inspecting Reference.java that it is basically a
>> stripped down type of List.  Could we use array or ArrayLists instead
>> of making a new container class?  If not, could Reference be renamed
>> to make it clear that it represents an array of values rather than a
>> single value.  Although I see that both "const SomeType arg[]" and
>> "const SomeType* arg" are translated to "References<SomeType>", since
>> they are functionally identical in C, but are semantically different.
>> (There are many instances of this.)
>
>
> Yes, this is a very serious issue.
> As you said, in terms of C, there is no way to distinguish [] from *
> Not only that, but in many locations the API defines a * for a table, or even a nil terminated list.
> I don't even want to go in details about reference for structs,double reference or even typedefs…
> The whole is a mess and with automatic tools this was the best I could do.
>
> Now, about the Reference object, it is primary a "reference", not an "array".
> It just happens in C that arrays are actually references to the first item in a list.
> References are more common to the iOS API than tables, since NSArray is used usually instead (and is properly mapped to a "List").
> These references (like NSError **) are used as "call by reference" arguments.
> So it's primary work is to provide a "pointer" and not a "table".
>
> What I actually did to automatically solve this issue, was a "trick", to support both references and arrays.
> The same object has behavior as a reference (with the get() and set() methods, without index) and as an array (the same methods with an index parameter). If you think that an ArrayList will be more appropriate than a fixed array, this is something that could change.
>
> I was also thinking of another solution - make everything as arrays.
> Then the callback variables will be a one-dimension, size-one arrays, but this will look a bit strange at first.
>
> If we want to do something more elegant that this (which I agree), I will be happy to provide an "XML API", in which will specifically define all those methods that need to be fine tuned.
> It won't be an easy job though.