A couple of suggestions

[Lauri Alanko <la la iki fi>]

Hello, there.

I have a couple of suggestions for gtk and glib. All of these are trivial to
implement, but I thought it best to ask for opinions before actually
starting tweaking anything.

So:

A GAny type, which would be an union of all the primitive types in glib.
This could be used as a "general" argument, where gpointer is used
currently. (Such as in gtk callbacks, hashes etc..) The current practice,
casting ints to gpointers and back, for instance, is not guaranteed to have
any consistent behavior. Though it appears to work on most systems, it is
still unreliable and ugly. Casting is a _conversion_ operation. Using an
union is cleaner.

For a real reinterpret cast (if such is really needed anywhere), the
following might be sensible:

#define REINTERPRET_CAST(x, type) (*(type *)&(x))

(or use a shorter macro name..) This of course needs an lvalue.

Then a real primitive hash would be useful, ie one which just stored objects
in the hash without any mandated key/value pairing..

And even the current hash should have a function to retrieve the key.
Otherwise, what's the use of GCompareFunc, if you get into memory allocation
problems if the key exists just in the hash and you can't free it..

In gtk, it would be good to have a

typedef guint GtkSignalID;

Or something similar. This just to make code clearer to understand. IMO,
unaliased ints should only be used for real numeric values. When ints are
used for identifiers and the like, it should be apparent from the code.

In addition, converting to this will make it easier to some day change the
type of the signal ids.

And finally, you can define signals without having to add a vtable entry to
the class object. That is good. It'd be nice to have a way to have virtual
methods without the overhead of signals, as well.


All of these are easy to implement, and all of them just add functionality,
they don't break anything. I'd be happy to do these. Are there any arguments
against these?


Lauri Alanko
la@iki.fi