|Maybe it is just me, but I don't see a problem with letting users access the
object with gobject methods. If |you look at the api, there aren't that many,
and there don't seem to be any that would harm too much. Also, |restricting
access too much prevents people from using it in (perhaps beneficial) ways that
you may not have |originally imagined.
|If you want to, you can override some of the original class methods, such as
{set,get}_property. But perhaps |using the methods to your advantage would be
better.
|Such as the {set,get}_property methods. You can let the user of the object
change parameters in this way, |rather than creating a dozen api calls to
change this parameter, or that one.
|Implementing signals could be nice also, let the user attach user-defined
methods/signals/hooks to events that |happen with your objects.
|Perhaps look at ways to use the gobject methods, rather than seeing them as a
way for users to get around your
|code...
As my library makes extensive use of threads and the objects created are
fairly complex (containing embedded objects themselves), allowing users
to manipulate or view object properties and/or attach signal hooks to them
is *precisely* what I am trying to avoid. I understand the "joys of gobject"
argument, but I wanted to frame the question in terms of a design decision
that has already been made, i.e. all pointers returned to the user are opaque
and understanding gobject is not mandated for programmers using the library.
Maybe I am making more out of this than need be. I have implemented thread-
safety in my api's; I require glib>=2.8 for thread-safe g_object_[un]ref used
internally; all of my gobject properties are construct only/write only; and
the user cannot subclass my objects using the public headers I provide.
Someone would have to go out of his/her way to discover that these are
gobject's,
let alone manipulate them using api's other than the ones explicitly provided.
Phil
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
