Re: GObject-Introspection 0.5.0
2008/9/7 Paolo Bonzini <[EMAIL PROTECTED]>:
>
>>> I'm leaning towards using the "ownership" terminology instead of "transfer".
>>> typedef enum {
>>>GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use
>>> */
>>>GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is
>>> */
>>> } GITypeOwnership;
>>
>> Just as a nitpick, these two names look very similar and quite confusing
>> for non-native English speakers. Maybe you could come up with something
>> different, especially in place of 'callee'?
>
> It's actually commonly-used terminology, e.g. "caller-save registers"
> vs. "callee-save registers" in compilers.
With all due respect I am not sure compiler-writers are the main
audience of GObject Introspection. I for one find the terminology a
bit confusing too.
--
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
On Sun, 2008-09-07 at 17:01 +0200, Johan Dahlin wrote:
> Alexander Larsson wrote:
> > On Mon, 2008-09-01 at 09:35 +0200, Johan Dahlin wrote:
> >> I'm proud to announce the initial release of GObject-Introspection.
> >> Colin Walters and I have been hacking madly on it for the past couple of
> >> weeks and we have finally reached a point to where we're ready for more
> >> more users.
> >>
> >> Tarball can be found at:
> >> http://download.gnome.org/sources/gobject-introspection/0.5/
> >>
> >> The goal of the project is to describe the APIs and collect them in
> >> a uniform, machine readable format. The initial target is language
> >> bindings,
> >> which are heavy users of this kind of data.
> >
> > I have a question about the details of GITransfer.
>
> GITransfer is still a bit in a flux as none of the existing (open) users
> use it yet.
>
> GITransfer is part of the typelib which hasn't yet been updated to the
> revised XML format. One of the main changes was to allow nested types
> definitions, and thus being able to specify things such as:
> - type of the list
> - type of the element
>
> I'm leaning towards using the "ownership" terminology instead of "transfer".
>
> typedef enum {
>GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
>GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is */
> } GITypeOwnership;
>
>
> Ownership examples of existing APIs:
>gtk_container_get_children: list = caller, element = callee
>gtk_icon_view_get_selected_items: list = caller, element = caller
>gtk_rc_get_default_files: list = callee, element = callee
So, your specify ownership twice, once for container and once for
contents? Makes sense to me.
The problem with the "transfer" terminology is that it takes a different
meaning for in args than for out/return args, and this way we can avoid
that.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
>> I'm leaning towards using the "ownership" terminology instead of "transfer".
>> typedef enum {
>>GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
>>GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is */
>> } GITypeOwnership;
>
> Just as a nitpick, these two names look very similar and quite confusing
> for non-native English speakers. Maybe you could come up with something
> different, especially in place of 'callee'?
It's actually commonly-used terminology, e.g. "caller-save registers"
vs. "callee-save registers" in compilers.
Paolo
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
Paul Pogonyshev wrote:
Johan Dahlin wrote:
[...]
> I'm leaning towards using the "ownership" terminology instead of "transfer".
typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is */
} GITypeOwnership;
Just as a nitpick, these two names look very similar and quite confusing
for non-native English speakers. Maybe you could come up with something
different, especially in place of 'callee'?
Agreed, I'm open to suggestions.
caller/subroutine ?
Johan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
Johan Dahlin wrote:
> [...]
>
> I'm leaning towards using the "ownership" terminology instead of "transfer".
>
> typedef enum {
>GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
>GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is */
> } GITypeOwnership;
Just as a nitpick, these two names look very similar and quite confusing
for non-native English speakers. Maybe you could come up with something
different, especially in place of 'callee'?
Paul
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
Alexander Larsson wrote:
On Mon, 2008-09-01 at 09:35 +0200, Johan Dahlin wrote:
I'm proud to announce the initial release of GObject-Introspection.
Colin Walters and I have been hacking madly on it for the past couple of
weeks and we have finally reached a point to where we're ready for more
more users.
Tarball can be found at:
http://download.gnome.org/sources/gobject-introspection/0.5/
The goal of the project is to describe the APIs and collect them in
a uniform, machine readable format. The initial target is language bindings,
which are heavy users of this kind of data.
I have a question about the details of GITransfer.
GITransfer is still a bit in a flux as none of the existing (open) users
use it yet.
GITransfer is part of the typelib which hasn't yet been updated to the
revised XML format. One of the main changes was to allow nested types
definitions, and thus being able to specify things such as:
- type of the list
- type of the element
I'm leaning towards using the "ownership" terminology instead of "transfer".
typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
GI_OWNERSHIP_CALLEE /* callee owns it, caller should leave it as it is */
} GITypeOwnership;
Ownership examples of existing APIs:
gtk_container_get_children: list = caller, element = callee
gtk_icon_view_get_selected_items: list = caller, element = caller
gtk_rc_get_default_files: list = callee, element = callee
Johan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection 0.5.0
On Mon, 2008-09-01 at 09:35 +0200, Johan Dahlin wrote: > I'm proud to announce the initial release of GObject-Introspection. > Colin Walters and I have been hacking madly on it for the past couple of > weeks and we have finally reached a point to where we're ready for more > more users. > > Tarball can be found at: > http://download.gnome.org/sources/gobject-introspection/0.5/ > > The goal of the project is to describe the APIs and collect them in > a uniform, machine readable format. The initial target is language bindings, > which are heavy users of this kind of data. I have a question about the details of GITransfer. Consider a function accepting/returning a list of objects. Is this right: In argument (g_arg_info_get_ownership_transfer): * GI_TRANSFER_NOTHING: caller owns list and objects * GI_TRANSFER_CONTAINER: callee owns list, caller owns objects (quite weird case, what function calls do this?) * GI_TRANSFER_EVERYTHING: callee owns list and object In return value (g_callable_info_get_caller_owns): * GI_TRANSFER_NOTHING: callee owns list and objects * GI_TRANSFER_CONTAINER: caller owns list, callee owns objects * GI_TRANSFER_EVERYTHING: caller owns list and object ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
