Re: GObject exposure

[Philip Kovacs <kovacsp3 comcast net>]

|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