Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Tim Janik]

On Wed, 14 Dec 2005, Dave Benson wrote:


people who want floating flags could always derive from GtkObject if they
don't want to reimplement it...


this is not an option for glib-only programs.



- dave


---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Tim Janik]

On Thu, 15 Dec 2005, Yevgen Muntyan wrote:


ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:

When you are calling your own code, it is not that much to keep track of, 
but when I write code that is used by 1000 developers it is much easier for 
me to take care of the reference issues inside the API and make the large 
group of unknown developers free from unknowingly creating reference 
counting bugs.



So, the thousands of another developers now will have to check
documentation for any GObject-derived class to figure out whether
they own reference or not. This is exactly why it's good when you
invent your wrappers, where it's clear that wrapper is made for
purpose and one might be interested in what that wrapper does.
So, if before the usage pattern was:

object = create_object ();
...
g_object_unref (object); /* I do know I own it */

now it will be

object = create_object ();
g_object_ref_sink (object); /* who knows what will happen in ... */
...
g_object_unref (object);


for the most part, users will not need to sink objects.
it's language bindings and container implementations that do this.
the floating flag is actually meant to make it easier on the user as
outlined in:

  
http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref

and for historic heritage see:

  gtk+/docs/refcounting.txt



These arguments about bugs and stuff are good arguments about why
one should use C++ or whatever other language with some sort of automatic
memory management.


this is absolutely correct. reall OO applications should be written in
languages with native OO support. 
for the scope of glib, gobject and gtk+, we're stuck with maintaining an

OO system implemented in C though, and we're simply doing our best to
live up to that expectation.



C is known not to be safe, and it's known that you
must be careful. After introducing floating references one will still need
to be as careful, but he also will need to check one more thing - floating
reference (or sink it as soon as possible).


no, you can treat a GObject with floating reference support the same way
you treat GObjects in older glib versions, as if it had no floating ref
support.


Maybe real solution would be for those 1000 guys to use mono or something?


unfortunately this always depends on other project aspects, like the platform
and programming skills. the deployment plans, etc. etc.


Regards,
Yevgen



---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Yevgen Muntyan]

Tim Janik wrote:


On Thu, 15 Dec 2005, Yevgen Muntyan wrote:


ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:

When you are calling your own code, it is not that much to keep 
track of, but when I write code that is used by 1000 developers it 
is much easier for me to take care of the reference issues inside 
the API and make the large group of unknown developers free from 
unknowingly creating reference counting bugs.



So, the thousands of another developers now will have to check
documentation for any GObject-derived class to figure out whether
they own reference or not. This is exactly why it's good when you
invent your wrappers, where it's clear that wrapper is made for
purpose and one might be interested in what that wrapper does.
So, if before the usage pattern was:

object = create_object ();
...
g_object_unref (object); /* I do know I own it */

now it will be

object = create_object ();
g_object_ref_sink (object); /* who knows what will happen in ... */
...
g_object_unref (object);



for the most part, users will not need to sink objects.
it's language bindings and container implementations that do this.
the floating flag is actually meant to make it easier on the user as
outlined in:

  
http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref 



and for historic heritage see:

  gtk+/docs/refcounting.txt



These arguments about bugs and stuff are good arguments about why
one should use C++ or whatever other language with some sort of 
automatic

memory management.



this is absolutely correct. reall OO applications should be written in
languages with native OO support. for the scope of glib, gobject and 
gtk+, we're stuck with maintaining an

OO system implemented in C though, and we're simply doing our best to
live up to that expectation.



C is known not to be safe, and it's known that you
must be careful. After introducing floating references one will still 
need
to be as careful, but he also will need to check one more thing - 
floating

reference (or sink it as soon as possible).



no, you can treat a GObject with floating reference support the same way
you treat GObjects in older glib versions, as if it had no floating ref
support.

Maybe real solution would be for those 1000 guys to use mono or 
something?



unfortunately this always depends on other project aspects, like the 
platform

and programming skills. the deployment plans, etc. etc.


Regards,
Yevgen



---
ciaoTJ



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Fwd: Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN]

Yevgen Muntyan wrote:

New code:

object = fancy_not_gtk_object_new();
g_object_ref_sink(object); /* because I don't know what will container do */
fancy_container_add(container, object);
g_object_unref(object);

What I want the container code to do is assert if an object is not floating, and
 ref_sink internally. So the user's code will look like:

object = fancy_not_gtk_object_new();
fancy_container_add(container, object);

Andrew Paprocki
Bloomberg LP



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Yevgen Muntyan]

ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:


What I want the container code to do is assert if an object is not floating, and
ref_sink internally. So the user's code will look like:

object = fancy_not_gtk_object_new();
fancy_container_add(container, object);
 


Exactly! Code of *your* users will look like that. What about me?
See, the problem is not the floating reference concept. We know that
it works nicely for widgets. The problem is that GObject exists, and it
works as it works. Changing it in such a way is not an enhancement,
it's real big change which requires more effort from me when I am trying
to write code without leaks (not like your users), and which adds more
inconsistency in GTK (see my note about TreeView and TreeModel).

Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Tim Janik]

On Thu, 15 Dec 2005, Yevgen Muntyan wrote:


I apologize for junk-posting, I'll learn to use mozilla next time.

Tim Janik wrote:


it's language bindings and container implementations that do this.
the floating flag is actually meant to make it easier on the user as
outlined in:


Let me expand my code samples:

Old code:

object = fancy_not_gtk_object_new();
fancy_container_add(container, object);
/* what do i do now? unref or not unref?
  yes, unref() because i own it */
g_object_unref(object);


because fancy_container_add() is documented to not take a reference.


New code:

object = fancy_not_gtk_object_new();
g_object_ref_sink(object); /* because I don't know what will container do */
fancy_container_add(container, object);
g_object_unref(object);


this will work if fancy_container_add() didn't change. also with floating 
GObject
this will work:
  object = fancy_not_gtk_object_new();
  fancy_container_add(container, object);
  g_object_unref(object);
as long as fancy_container_add() didn't change.

with and without floating support fancy_container_add() may change though.
e.g. it may always take a reference, to which you'd have to adapt your code then
(remove your unrefs).
or it may randomly take a reference, to which your code would be hard to adapt
without leaks.
or it may sink the obejct, to which your code would be easy to adapt again
(remove your unrefs).

the point is, you only have to adapt your code if fancy_container_add()
changes, and that can occour regardless of libgobject changes.

the only relation existing here is:
  fancy_container_add() cannot sink GObjects as long as libgobject does not
  support floating objects.

and we'r about to change that. the only thing libgobject will do is to
*enable* fancy_container_add() changes wrg sinking though. nothing more.

so adding floating ref support to libgobject doesn't change any GObject
refcounting semantics at all. it's the fancy_container_add() changes in
other projects that are enabled to change semantics then, and whether
they do that, and if that's compatible or incompaatible will be up
to the maintainer of fancy.


So far we have had one simple rule - GtkObject has floating reference, it's
supposed to be taken by parent, whether it's parent GtkContainer or


GtkObject per se doesn't even introduce parent-chuild relationships,
it's GtkWidget that does this. (and some containers take non-widget
GtkObjects).
and note that libgobject hasn't been floating reference-free anyway,
GParamSpec already had floating references as had GClosure.
so, maybe it's not as siple as you'd think ;)


GtkTreeViewColumn for GtkCellRenderer, whatever. Now, we have a trouble.
Will GtkTreeModel be sinked by GtkTreeView? I believe it should be (if we are


that depends on whether it could compatibly be ported to that behaviour.
cou could e.g. be deprecating one model setter and adding another, or you
could not support sinking at all, etc...


consistent and everything). But it can't, because you get crash in old code.


that sounds like a non-compatible change then ;)


  http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref 


and for historic heritage see:

  gtk+/docs/refcounting.txt


Is it not correct that floating reference in GtkObject is one of
well-known sources of misunderstanding/problems for bindings?


with bindings you mean langzage bindings?
i'm not really worried about confusing language binding authors, because
there's only a finite oevrseeable number of them. anyone wanting to code
up a proper language binding for gtk/glib will have to come here and get
informed about a couple involved topics anyway. floating references aren't
too complicated for that scope by my experience (they just need to be
explained which the docs i pointed you at should take care of already).


And
that it should not exist at all, but it exists only for historical reasons 
and

convenience of gtk_container_add(container, gtk_label_new())?


it exists for C convenience. that's what the official API reference doc says:
 
http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#floating-ref

C convenience is an iomportant concern for a C toolkit with large amounts of
depending C applications. so that basically justifies having a floating
reference at all.


These arguments about bugs and stuff are good arguments about why
one should use C++ or whatever other language with some sort of automatic
memory management.



this is absolutely correct. reall OO applications should be written in
languages with native OO support. for the scope of glib, gobject and gtk+, 
we're stuck with maintaining an

OO system implemented in C though, and we're simply doing our best to
live up to that expectation.


I am not saying that glib should be written in other language. And I agree
that glib should try to solve users problem. But it should not solve problems
of lazy users by adding problems for others.


i don't think this 

Re: Fwd: Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Tim Janik]

On Thu, 15 Dec 2005, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:


Yevgen Muntyan wrote:


New code:

object = fancy_not_gtk_object_new();
g_object_ref_sink(object); /* because I don't know what will container do */
fancy_container_add(container, object);
g_object_unref(object);


What I want the container code to do is assert if an object is not floating, and
ref_sink internally. So the user's code will look like:

object = fancy_not_gtk_object_new();
fancy_container_add(container, object);


asserting floating state is usually a bad idea, because the floating
reference count is a one-shot indicator for unknown object ownership.
once the ownership is clear, the object shouldn't become less usable
(certainly bad for the owner ;)

that'd disallow scenarios like:

  object = fancy_not_gtk_object_new();
  do_stuff (object);
  fancy_container_add(container, object);

where do_stuff() could be adding + removing to/from another container.
or it could be:
  do_stuff (object) { this-list += g_object_ref_sink (object); }
  // destructor cleans up this-list

or it could be setting up a python/perl/etc. proxy for object.
or maybe you have:
  object = from_perl_code_create (SomeObject);
or:
  object = UIFactory::create_object (XmlFileObject);
which return already sunken objects.


Andrew Paprocki
Bloomberg LP



---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: Re: GTK_FLOATING broken in 2.9?

[Yevgen Muntyan]

ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:

When you are calling your own code, it is not that 
much to keep track of, but when I write code that is used by 1000 developers it 
is much easier for me to take care of the reference issues inside the API and 
make the large group of unknown developers free from unknowingly creating 
reference counting bugs.
 


So, the thousands of another developers now will have to check
documentation for any GObject-derived class to figure out whether
they own reference or not. This is exactly why it's good when you
invent your wrappers, where it's clear that wrapper is made for
purpose and one might be interested in what that wrapper does.
So, if before the usage pattern was:

object = create_object ();
...
g_object_unref (object); /* I do know I own it */

now it will be

object = create_object ();
g_object_ref_sink (object); /* who knows what will happen in ... */
...
g_object_unref (object);

Is it really good for glib, the library which is used by all people 
using glib,

not just those 1000 unknown developers who are not aware of the need
to free allocated memory?

These arguments about bugs and stuff are good arguments about why
one should use C++ or whatever other language with some sort of automatic
memory management. C is known not to be safe, and it's known that you
must be careful. After introducing floating references one will still need
to be as careful, but he also will need to check one more thing - floating
reference (or sink it as soon as possible).
Maybe real solution would be for those 1000 guys to use mono or something?

In short, it's nice that glib will be more safe for those who do not check
what his code does, but if one tries to write safe code, he'll get one more
headache.

Regards,
Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list