[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Sinkability considered harmful
From:       Tristan Van Berkom <tristan.van.berkom () gmail ! com>
Date:       2006-01-07 20:32:00
Message-ID: 43C02540.5040208 () gnome ! org
[Download RAW message or body]

Tim Janik wrote:
[...]
>> People have to get over it.
> 
> 
> well, i think the question here is whether we assist them with appropriate
> functionality, or let everyone learn every possible memory management 
> failure the hard way over and over again. the latter is prone to produce
> bug-ridden software and be way less productive (see the mythical man month
> on why it is important to reduce the klocs one has to write to achive
> a given task).

I'm sorry;
     I havent been present on the internet for 2 days and I know I'm not
ringing in the tempo here but; I think that argument is completely unfair.

Its not by reducing the code-size by one line every created widget in
a interface-building code segment that you make life easier to a programmer;
as specially not for a beginner (although it may be convinient for a
handfull of gtk+ gurus that happen to know it safe to not unref the
out-of-scope resource).

IMO; to "assist them with appropriate functionality" means to give them
a sane and consistant fully refcounted api.

furthermore; to diverge from this ideal uniform API (regardless of the
extra g_object_unref() after every gtk_container_add()) is to add one
more "possible memory management failure" to be learnt the hard way
again and again.

Is there a paper, an RFC or anything on the internet where I can
read what exactly are the arguments *for* implementing floating
GObjects ?

The way I see it; arguing that GObject should be consistant with
GtkObject is a non-argument; floating GtkObjects is backwards by design
and even if you dont share that opinion; you cant force all created
GObjects to be floating without breaking existing code; so you'd still
have to look up; object by object; which ones are floating after
construction and which ones arent, in the end; this does nothing
for GTK+ api consistancy and it reduces GObject api consistancy.

I haven't committed a wealth of patches to the GTK+ project but I
feel very fond of it, for whatever little my opinion is worth here
I urge you please please hold your breath and pull it out of this
release at least so we can look at all of the alternatives.

Cheers,
                          -Tristan

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]