Re: [gnome-db] Patch for const removal



Murray, you wrote, "The only consistent and workable use of const that
I have seen in GNOME is on gchar* parameters. Anything else might lead to
problems."  And Rodrigo agreed with you.  Could you help me out here?


> In this special case, since it doesn't impose other
> problems, it makes perfect sense to force the user to cast to (const
> GList *) the value passed to this function.

It never make sense to force a user to cast const.

Anyway, that isn't a problem with your model.  Having extraneous constin a
function argument isn't noticeable to users.

> 	gda_data_model_append_row (model, const GList *value_list)
> 
> explicitly states that the value list is going to be read by the data
> model implementation and forget about it. Whereas:
> 
> 	gda_data_model_append_row (model, GList *value_list)
> 
> can be thought as of "the value_list is kept by the model"

AFAIK, this isn't the standard C meaning of const.  And I can't
find a GNOME example that use const on objects.  Are you proposing
a libgda-specific meaning for const here?

What do you mean by "value_list is kept by the model"?

  1) value_list->data is g_ref by the model
  2) value_list->data pointers are saved by the model
  3) value_list pointer is saved by the model

If other GNOME projects went by your logic, shouldn't these
functions have const in them?

  g_list_copy (GList *list)
  gtk_container_set_focus_chain (GtkContainer *container, GList* list)
  GSList*     gtk_accel_groups_from_object    (GObject *object);
  

> Also, on the gda_value_new... functions, keep the const for the argument
> also. I think it's better to keep it there. The same for the gda_value_get...
> and gda_value_set... functions.

With gda_value_new and gda_value_set, you probably are using the
same reasoning as above.  But why gda_value_get_* ?

:-),



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]