[Workman-devel] [PATCH 4/4] Add attributes property to WorkmanObject

[Daniel P. Berrange]

On Mon, Mar 04, 2013 at 08:31:17AM -0600, Josh Poimboeuf wrote:
> On 03/04/2013 04:49 AM, Daniel P. Berrange wrote:
> >On Fri, Mar 01, 2013 at 02:18:15PM -0600, Josh Poimboeuf wrote:
> >>
> >>I got it to work using the annotations I mentioned above, combined with
> >>some get_type() boilerplate.  I verified that the generated gir file
> >>showed the contained type:
> >>
> >>       <property name="attributes" writable="1" transfer-ownership="full">
> >>         <type name="GLib.List">
> >>           <type name="Attribute"/>
> >>         </type>
> >>       </property>
> >>
> >>However, I'm wondering if this is the best approach...
> >>
> >>You mentioned the possibility of just not creating the property.  I kind
> >>of like that idea because it gets rid of a lot of boilerplate code, for
> >>this class and for all the others.  Do you see any problem with just
> >>not having *any* properties and only supporting the API interfaces?
> >>
> >>The only real downside I can think of would be that we'd have to use
> >>"protected" functions to set the name, state, attributes, etc when
> >>initializing a subclass object.  And GObject protected functions are
> >>kind of a joke, as they seem to be based on the honor system (i.e. a
> >>"/* protected */" comment).  But I don't think that's a big deal.
> >
> >I'm not sure I follow you on the 'protected' functions thing ? What
> >functions are you thinking of in particular ? I think it is fine to
> >not have a property for the list of attributes, and just let people
> >use the workman_object methods for fetching/manipulating attributes.
> 
> Without an attributes property, we'd have to create a set_attributes()
> method.  But I don't think it makes sense to expose that method as part
> of the API.  We'd only want to let subclasses (and maybe other classes)
> use it.  But *not* users of the library.  That's what I meant by a
> protected function.

Ah, ok, I get what you mean now.

Since I don't anticipate us allowing out of tree subclasses just yet,
how about we punt on the problem and just create a workman-object-private.h
file containing the workman_object_set_attributes() method, and not instal
that header file into /usr/include

> A similar issue exists with other properties like name and state.  In
> the current design, they're immutable and would only be set during
> initialization.  We wouldn't want to expose their setters as part of the
> API.  Object properties are a way to enforce that.  But properties add
> a lot of boilerplate to maintain, so I was wondering if we could get
> away with not having *any* properties at all.

The main reason glib uses he properties concept is that it makes like
nicer for many non-C languages. For example, it is common practice in
dynamic languages to use   foo.bar = 1 instead of f.set_bar(1), and
properties let you do that. So I think that's worthwhile in general,
even though it adds tedious boilerplate to the clsases.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|