Re: [xmlvm-dev] Automatic generation of iOS Java API

[Panayotis K. <pan...@pa...>]

In the past you asked me if I will deal with C functions as well.

I am exactly at this position.

From what I see there are 2582 functions (which need to be included in objects :) )

1714 are easy, since it exists an object which has the same name as the beginning of the function.

The problem is with the remaining 868 functions - what would be the easiest way to group them and make this easy for the developer to find the function he wants.
 
Let's take two simple examples

1) the functionNSUserName which returns the user name.
This function doesn't match to ANY known object up to now.
It partially matches though the "NSUserDefaults" object. 

2) A "cluster" of functions, such as 
CFNetworkExecuteProxyAutoConfigurationURL
CFNetworkExecuteProxyAutoConfigurationScript
CFNetworkCopyProxiesForURL
CFNetworkCopySystemProxySettings
with (or without in another cases)  matching object



So, here is what we can do for these unmatched cases:

1) Create a "framework object" and put everything there 
(like what we did with NSSearchPathForDirectoriesInDomains function)

2) Aggressively match a function to an object. Only the remaining functions will be put in the framework object.

3) Create a new "cluster" object (e.g. in the second case described above) which will host these functions.
We can either be aggressive there (i.e. create a CFNetwork object) or reluctant (i.e. create an "CFNetworkExecuteProxyAutoConfiguration" and "CFNetworkCopy" object).


The second solution I believe will confuse developers. He'll have to search for a specific function instead of knowing where to look at, if he already knows the name.

The third solution is problematic, since it would be difficult every time to calculate the exact name. E.g. the functions starting with "CFPlugIn" could not provide a good aggressive name, while being reluctant will produce many small almost-empty objects.
Even if we provide externally the information on how to break the names apart, it still would be difficult for the developer because he won't be inside our mind, when we created this partition scheme.

For these reasons I am more in favor of the first solution, since it would be clear and obvious to the developer, that if a function does not start with a well defined object (or struct) then it will "live" in the framework object.


Next step will also be mapping enum's and where to put them.
Most (all?)  of the enumerations correspond to specific objects, although sometimes (for space reasons?)  the name of some of them are truncated a bit.
For this reason I am more in favor of the second approach.

So, what do you think?