[M3devel] UI, Trestle, native... Cocoa??

[Darko]

I agree there is benefit in having some high level semantics, but they can be easily derived or entered manually in a high level spec that complements what has been parsed. The tool can accommodate those requirements. But most of the work is getting the declaration information and that's not practical to do manually. For instance the Carbon interfaces I translated resulted in an interface file with over 60,000 lines. The Cocoa interfaces are somewhere in the order of 5 - 10 times that size and growing.

I'm not suggesting macros should be attempted to be parsed and I think no programmer can code without referring to the reference manual. In most cases the text that is in the reference manuals for Cocoa is derived from comments in the header files.

One of the benefits of your own tool is that you have a high degree of control over the translation and that means you can make the generated interface more predicable, making the reference material more useful. For instance when the Carbon interfaces were translated the C idiom of passing pointers in function call parameters was converted to VAR parameters in M3 since that was the intention in 99% of cases.


On 29/09/2010, at 2:53 AM, Mika Nystrom wrote:

> Darko writes:
> ...
>> 
>> I don't understand where the payoff is in doing anything else when there =
>> is no way of reliably automating it and making it output something =
>> clean, putting you back to square one and having to hack anyway. A =
> ...
> 
> As long as you also generate syntax-correct C code from a higher-level 
> specification there should be no extra "hacking" involved.
> 
> The main thing you can get with a higher-level representation is the
> same thing you get with .i3s: annotation of memory management.  If your
> library allocates and deallocates objects, you can then automatically
> generate wrappers that use WeakRefs for instance.  (If you like.)
> Or you can generate another, totally different interface automatically
> (the one on the "other side" of the glue code).  There are many things
> you can do with a suitable higher-level specification that you can't do
> with .h files alone...  Sorry, I mean there are many guarantees you can
> provide that you can't get with .h files.  Generally there are too many
> things you can do with .h files that you really don't want to do...
> 
> And in my experience C headers sometimes use nasty things.  Macros are a
> pain for instance.  Sure you can make syntactically correct .i3s fairly
> easily, but there is no way of knowing how to call them from reading just
> the .h; the programmer is reduced to reading machine-generated interfaces,
> which is never a pleasant thing.
> 
>      Mika