Re: Third draft (was Re: defs files)



"Emmanuel DELOGET" <logout@free.fr> writes: 
>     well... I think glib can be the module of the
>     basic glib types (just as gint and gpointer)
> 

I'm more or less ignoring glib as "too low-level to wrap by machine."
Also glib typically overlaps with native language facilities, since C
is about the only language so broken that it has no native container
types.

This may be partially wrong; I guess stuff like the main loop could
maybe be wrapped. I don't know. Any opinions?

In any case the module is "G" rather than "glib", which is a bit
weird...

> Should prefer to have a :
> (defined-type
>     (alias a)
>     (in-module m)
>     (gtk-type-id id))
> 
> and :
> (used-type
>     (use-defined-type t) ; probably not so useful
>     (alias a)
>     (c-name name-of-symbol-in-C))
> 
> This should be probably clearer and more flexible
> than the in, inout and out attributes.
>

OK this is basically how I had done things originally, with all the
data stored in the type, instead of having in/out/inout modifiers on
the function parameter. So you'd have in-string, out-string,
return-string, in-string-that-should-be-const, etc. I changed it in
response to other comments. :-)

The modifiers on the function parameter are perhaps somewhat more
readable or convenient or logical in some way. I think when it comes
down to it both ways will work.

Havoc



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]