Re: Should we wrap accessors for properties?

[muppet <scott asofyet org>]

On Aug 11, 2008, at 8:05 AM, Torsten Schoenfeld wrote:

> I'm going through the new API in gtk+ 2.14.  As usual, there are  
> quite a few
> accessors added for new properties.  For example,
> gtk_calendar_get_detail_height_rows and
> gtk_calendar_set_detail_height_rows for the "detail-height-rows"  
> property of
> GtkCalendar.  I wonder if we should continue to wrap those.
>
> The new properties are automatically available via the generic  
> property
> mechanism ($object->set (foo => ...) and $object->get ('foo')).  I  
> see two
> downsides:
>
> * Decreased visibility of the new possibilities.  There are no  
> accessors
> listed in the methods section of POD pages anymore.  The properties  
> section
> will still list the new properties, of course.

For better-documented libraries, however, the documentation strings  
are included.  Score!


> * A slight speed disadvantage of using the generic mechanism  
> compared to
> specialized accessors.

I think that might be nicely offset by the memory savings for not  
filling up the symbol table with xsubs for stuff you can already get  
through the property interface.  *shrug*


> The upsides would be less work for us and a smaller size of the  
> wrapper
> library which means faster load times.
>
> What do you all think?


We had considered this once before, quite early on.  However, at that  
time there were several seemingly high-profile exceptions to the  
property vs getter/setter function pairings, and we already had the  
precedent of lots of methods.  Of course, i can't think of any now,  
but this is what i remember.

Another possibility is using that evil AUTOLOAD pixie dust to nuke  
large portions of the bindings and create accessors and mutators on  
demand.  The biggest thing to worry about would be potential name  
collisions.

One of our early attempts at making properties easier to use was  
Glib::Object::tie_properties(), which made the properties visible as  
hash keys on your instance.

http://gtk2-perl.sourceforge.net/doc/pod/Glib/Object.html#_object_tie_properti

The drawback was that you had to be very careful how you use the keys,  
and watch out for interactions between the property names and real  
hash keys.  In retrospect, it would've been cleaner to use a separate  
"properties" hash.


--
The Master in the art of living makes little distinction between his  
work and his play, his labor and his leisure, his mind and his body,  
his education and his recreation, his love and his religion. He hardly  
knows which is which. He simply pursues his vision of excellence in  
whatever he does, leaving others to decide whether he is working or  
playing. To him he is always doing both.

  -- Zen Philosophy