On Mon, 2006-08-21 at 20:04 -0400, Philip Kovacs wrote:
> I have a question related to whether or not I need to go to more deliberate
> lengths to hide/shield the gobject's I am producing from the users of my
> library.
>
> The api's I have implemented deliver (what I wish to be) opaque pointers
> to the users of the library. There are _new, _free and a whole suite of
> other functions I have implemented. The fact that these are gobjects is
> not revealed to the user. The public headers never expose glib-object.h
> or any of the standard gobject macros. Yet, under the covers, they are
> gobjects and a savvy user *could* include glib-object.h and manipulate
> them as such.
>
> Is it advisable to wrap the gobjects in structures so they cannot be
> manipulated
> using anything other than my api's?
>
> typedef struct _the_object
> {
> gint cast_guard; /* so you can't cast THE_OBJECTS to
> the inside gobject */
> GObject the_object_real;
> } THE_OBJECT;
Well, they'll still be able to get at the underlying objects by indirecting
past the guard. Even if you make the struct opaque they'll still be able to
find out its layout by inspecting memory (pointers are very obvious). Perhaps
you should pass around indexes into a private global pointer array?
Or perhaps you should accept that users are capable of shooting
themselves in the foot in ways you've never dreamed of, and let things
stand with a sufficiently strong warning in the documentation.
Ed
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
