Re: FEATURE FREEZE

[Tim Janik <timj gtk org>]

On Tue, 12 Jan 1999, Paolo Molaro wrote:

> Tim, I don't think you're palying fair, here: I sent the patch to
> gtk-devel-list for comments at least two days before committing it.
> If you had so many concerns you could have said them before...

unfortunately i've been off the net for about 4 days and wasn't able
to send or receive any mail within that period. but apart from that,
it should be pretty clear to people that we are in feature freeze
and bug fixing mode currently and have to stop adding feature over feature.

> On Mon, Jan 11, 1999 at 12:43:08PM +0000, Gnome CVS User wrote:
> > CVSROOT:	/debian/home/gnomecvs
> > Module name:	gtk+
> > Changes by:	timj	99/01/11 12:43:08
> > 
> > Modified files:
> > 	.              : ChangeLog 
> > 	gtk            : gtktypeutils.c gtktypeutils.h 
> > 
> > Log message:
> > Mon Jan 11 13:31:49 1999  Tim Janik  <timj@gtk.org>
> > 
> > * gtk/gtktypeutils.[hc]: removed Paolo Molaro's type creation hooks
> > again, since they 1) don't care about infinite recursion (likely
> > to achive), 
> 
> Well, I guess your implementation of 
> g_hook_list_marshal_check(GHookList*, gboolean may_recurse, ...); 
> doesn't work then as I call it with may_recorse = FALSE.
> If you think someone could create a new type from within a
> creation handler, that can be considered an appllication bug: it's
> about the same limitation there is in your implemetation of the
> signal emission hooks.

signal emission hooks may recurse, they may just not modify the current
emission. type creation hooks may not recurse, as you said, an app that
installs a type creation hook should be considered buggy as it most likely
is on its way to create an infinite loop, but similar to the signal code
that checks for emission modifications from emission hooks, the type creation
hook code can check for such situations and needs to honour that with a
warning.

> > 2) we are in feature freeze for 1.2. this definitely
> 
> Those are two small functions that don't affect other's code and that
> enable us to more effectively use Gtk: it's the same difference
> between polling (old behaviour) and select()ing.

i'm not at all against implementation of type creation hooks, but we
are in feature freeze and have to stop somewhere. i personally have other
small functions pending as well that are not very likely to introduce bugs
and are even extensively tested already (e.g. unix signal handlers for glib's
main loop or multiple interfaces for gtk), but if we keep adding features
we will never get a 1.2 out of the door.

> > deserves a sane implementation in 1.3 though (but without a hook
> > return value,
> 
> Please explain why you don't want that feature.

timeout or idle functions are usually very dynamic functions they get added
at random and often are used for one-shot invokations only, there it makes
much sense to return whether they should be deleted after invokation or
not. this is not the case with type creation hooks, you'd usually setup
the hooks when your interpreter starts up and leave it at that, so for
the common case, the return value is just overhead.

> > without seq_id hackery and with recursion checks).
> 
> That code is a cut&paste from your implemetation of the signal
> emission hooks: are you going to remove that also? I hope not.

that's a different matter, gtk_signal_add_emission_hook_full() sets up
emission hooks for different emissions and therefore different hook lists,
but has to take care to still assign unique sequential ids, that's why
the seq_id on the hook list gets set prior to hook prepending and gets
saved afterwards. for type creation hooks, you'd simply want to omit
that hackery.

> 
> lupus
> 

---
ciaoTJ