Re: Ideas for new API

[Gustavo Carneiro <gjc inescporto pt>]

On Tue, Jun 22, 2010 at 11:29, Richard Gipps <rgipps netspace net au> wrote:

On 22/06/10 01:51, Damon Chaplin wrote:

On Mon, 2010-06-21 at 22:28 +1000, Richard Gipps wrote:
 

Damon,
             I have used the model/view option when creating my own
GooCanvas Classes (models/views) because I thought it may be useful in
the future rather than because I specifically needed a model/view split.
If this functionality is removed will writing custom GooCanvas items
still be fairly straight forward?
   

Creating a subclass of GooCanvasItemSimple is exactly the same at the
moment - just define the 3 methods update/paint/get_item_at.


 

When you say change the item XXX_new() functions do you mean get rid of
them so that one has to use g_object_new( ) or do you have another
cunning plan?
   

I'd like to keep the XXX_new() functions, as they are handy in C and
much faster than using GObject properties. I just wondered if there is a
slight variation that is better for bindings.

Damon
 

That sounds good, the XXX_new() functions are very handy and they make the code much easier to read and interpret. I was a bit worried you were going to dispose of them for a minute:)

The problem of XXX_new() functions is that they hardcode the GType of the GObject to be constructed, and therefore cannot be used when subclassing.  And in fact the mere existence of these functions allow the library developers to provide functionality that is only available through these functions and therefore not available in subclassing.  Let me give a fake example.  Suppose we have a function like:

   GtkWidget *label = gtk_label_new("string");

Now suppose there is no property and no setter function for the label text.  Then, if you try to subclass GtkLabel, you two choices:

   1. Continue to call gtk_label_new.  But this constructs a GtkLabel object as before, not MyLabel or whatever -> no subclassing.

   2. Call g_object_new (MY_TYPE_LABEL); but you cannot set the label text unless there is a setter function or object property.

In pygtk we had occasional problems like these, gtk_xxx_new_with_yyy functions that provided functionality that we could not find in equivalent property and/or setter function calls.

If the developers are careful to not to make these mistakes, there is nothing wrong with xxx_new() functions.  If those xxx_new() functions are not provided then we can be absolutely sure such mistakes won't happen, or else the library wouldn't be functional even for C programmers.

I'm not saying, don't make xxx_new() functions.  I'm advising to be careful.  Ideally, each xxx_new() function should just map into a single g_object_new API call (with a bunch of construction properties), to make sure the object can be constructed via g_object_new without losing functionality.

Regards,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert