Re: A couple of suggestions

[Lauri Alanko <la iki fi>]

On Tue, Apr 07, 1998 at 12:24:49PM -0400, Owen Taylor wrote:
> > >Could you eloborate? key/value pairing seems like a pretty
> > >essential part of a hash to me... (Without that 
> > 
> > Sometimes the key is a part of the value, or for other reasons the
> > default pairing doesn't suit you. And sometimes you just want
> > a set, from which you can check if a particular object is there.
> 
> How about just using the same pointer for the key and the value?
> (It takes up a bit more memory than a new data type, but has
> the advantage of already being implemented)

Yes, or just using a null value if you can retrieve the key. This is
reasonable, but I felt that wasting one third of the node memory is rather
inelegant. I experimented with a more generic hash, but I didn't find an
acceptable mix of generality and ease of use.

> > Or for the case when you want to use ints the "right way", having
> > pointers to ints. Then you need to allocate an int for each of your
> > keys. Then how are you supposed to remove it? All that's needed is a
> > way to get the actual key object in the hash.
> 
> OK, I see your point now. Currently, you'd have to store a pointer
> to the key in your value, if you wanted to be able to remove
> single entries from the hash table.
> 
> Something like:
> 
> gboolean    g_hash_table_lookup_entry (GHashTable     *hash_table,
>                                        const gpointer  key,
>                                        const gpointer *key_return,
>                                        const gpointer *val_return);
> 
> would probably be useful in such circumstances.

Yeps. I will add it. I'll do a bit of code cleanup, too, changing if
(hash_table) {...} to g_return_if_fail (hash_table) which at least issues a
warning.

I'll also add a function to force rehashing, if the user consciously does
something that screws up the hash, such as modifying a key so that its hash
value is different.

> > You never know of the future. Isn't it conceivable that some day, for
> > efficiency reasons, you don't get an id but a direct pointer to a
> > signal structure?
> 
> I suppose it is conceivable.

What is the idea with the signal ids, in any case? Pointers to unknown type
are quite as opaque, and faster. And the extra level of indirection is
confusing.

> > Oh, one more idea: a list that keeps track of both its
> > ends. Basically:
> > 
> > struct _GDList{
> > 	GList *head;
> > 	GList *tail;
> > };
> > 
> > And a similar one for GSLists. What's the use? Both access to head and 
> > tail become O(1) operations, and you could use these without the
> > bothersome list=g_list_foo(list) syntax.
> 
> I've occasionally wanted something like that. The only real downside
> would be a fair amount of code duplication in GLIB. And you 
> could in most cases simply wrap the g_list functions. 

Not any more duplication than already with GList/GSList, I think. And the
speed and syntax benefits weigh more, IMHO.

> (I don't see that much of a point in the GDSList, though - having the
> tail isn't much use if you have to traverse the whole list to 
> get the element before it)

Well, a GDSList would be optimal for a FIFO. You read from the head and add
to the tail.

> > Oh, one more thing. Why not have 
> > 
> > typedef void (*GtkSignalFunc) ();
> 
> Sounds like a good suggestion to me. Though note that a large
> fraction of GTK signals (all the _event ones, plus some others)
> _do_ have return values. So the GTK_SIGNAL_FUNC() casts would
> still be needed in many places.

All right, I'll change this too, if no one else has. Shouldn't this be moved
to gtksignal.h, btw?

IMHO, handlers returning values is just syntactic sugar, though.. not sure if
it's worth the marshalling overhead..

Speaking of which, wouldn't it be sensible to have more marshallers than
just the default one in gtksignal.h? At the very least a marshaller for
signals that have one gpointer argument, these are needed everywhere.

> It doesn't help things for people using C++, where the empty
> parens are equivalent to (void) but it doesn't make things worse
> for them either.

Ah, and regarding this, why are there extern "C" {..} :s wrapped around all
headers? GTK has no support for C++, it's plain C code, so IMHO it's should
be the C++ user's responsibility to say extern "C". Also, it screws up
emacs' indenting. :)

(Gee, why do I always forget something out?..)

_Yet_ one more thing, relating to the previous.

There are lots of

struct _Foo {int dummy;};

:s in glib.h and gdk.h. I can't see any justification for these. They make
it look like the user code knows these types, and happily allows the user to
allocate these.

The right thing to do would of course be just to have the

typedef struct _Foo Foo;

which has a forward declaration for struct _Foo, and allows the user to
handle pointers to it, but not access it. Then the implementation code would
have the definition for struct _Foo.

I can't think of any other reason for this than that Peter just overlooked
this... Removing the dummy definitions shouldn't break anything, nor should
then simplifying the implementations by removing the "real" type casting..

Ugh, and yet a couple of things.

GtkStyle doesn't seem to allow null pixmaps as a background. This is a bit
of a deficiency. 

And second, has there been any thought of caching successive expose events?
This shouldn't been too hard to do..


Well. That was about all for now. More when I again remember something I
should have said here..


Lauri Alanko