Re: Second draft (was Re: defs files)

[Havoc Pennington <hp redhat com>]

Owen Taylor <otaylor@redhat.com> writes: 
> So, your proposal takes a very different approach, which is simply to
> reformat C types in a way that is slightly more convenient to
> parse. (You've added sugar and aliases to make it look a bit more like
> the first approach, but I don't think that this is a
> mischaracterization.)
> 

It's not quite true; the idea is just to have "type" objects that
assign an arbitrary name to some lump of type properties.

Perhaps confusingly, I was using the C name for the name. You could
easily just use a serial number.

Anyway in the next draft I've reworked the type defintion stuff.
I'm still using a human-readable type alias name. This may be a
mistake; the identifiers are supposed to be totally arbitrary, 
the other information provided should be sufficient to output
bindings. The type alias is just a way to refer to the blob of info
about a type.

> I'm not in favor of this:
> 
>  - There _is_ semantic information beyond the simple C types.
>    For instance, the information that a returned char * must be freed.
>

So the idea was that you would have in-string out-string inout-string
etc. named types, and the blob of type information labelled by
in-string would contain the info that the string is to be treated as
an "in" parameter. I've changed it so that in/out/inout are now given
in the (parameter) definition. However in/out/inout don't mean
anything in the "native" case (which I've also added).

>  - The C type representation may not be unique. For instance, is 
>    'GtkWidget **' 'out GtkWidget *' or 'array of GtkWidget *' you
>    can't tell.
> 
>    We can disambiguate this in the header files by adding magic comments,
>    but if your defs file format is build around C types, then you'll
>    need some clumsy way of disambiguating it there too.
> 

This would simply be handled by creating a different blob of type
information with a different name.

>  - I don't fully understand your proposed mapping between C types
>    and type names, but it seems to be rather ambiguous in a few
>    places. 
> 
>    - If you mean to preserve the current approach in the defs file of
>      converting '_' to '-' in all names, then you don't even have a
>      unique mapping.
> 

No I'm not doing that at all, just using - to escape spaces.
The exception is the names of enum values, where the rule is "strip
prefix, lowercase, underscore->hyphen".

>    - It's not at all clear what you do with complex declarations
>      with (), [], function declarations, etc.
> 

Ignore them, [] can always be treated as a pointer in the GTK cases,
function pointers are always typedef'd except some broken crap in
GNOME we don't care about.

If [] has an explicit size you could add it to the blob of type
information somehow.

> If you need to preserve the original C types for the C-specific parts
> of the GTK+ API, then you should simply preserve the actual C declarations
> with something like:
> 
>    (function cmap_new
>      (in-module (Gdk Rgb))
>      (c-name gdk_rgb_cmap_new)
>      (return-type GdkRgbCmap*)
>      (parameter (type-and-name native colors)
>                 (c-declaration "guint32 *colors"))
>      (parameter (type-and-name gint n_colors)))
> 

Done.
 
> You need to merge the (destroy...) and (unref-func...) to be simply
> (release...).

Done.

> It's possible that ref-func and copy-func should be kept
> separate, since they encapsulate a distinction between a shallow copy
> and a deep copy. However, I'm not really sure that is valuable either,
> because these type descriptions are meant to be used for the purposes
> of internal memory management of the language binding, so one or the
> other should be picked, and it should be consistent between language
> bindings.
>

Well, I need this distinction for Sugar I know, so it must be
useful... as we discussed though the same thing is probably encoded in
whether or not the ref-func returns a value (some ref funcs return a
value but can be treated as copy funcs in that case).

Conceptually though, objects should be able to have both.
It should be possible to either deep or shallow copy.
 
> Also, I think that structures-by-value should be separated from boxed
> types - they are conceptually different, and they also map into C
> slightly differently. For instance:
> 

Done.

Another draft forthcoming...

Havoc