Re: A couple of suggestions

[Owen Taylor <owt1 cornell edu>]

Lauri Alanko <la@iki.fi> writes:

> 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.

[...]

> 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.

In that case, couldn't one remove that key and re-add it? That's all
the operation would come down to, right? Unless you mean rebuilding
the entire hash table, which would be an expensive operation.
 
> > > 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.

Perhaps Tim has some ideas on this... I don't really know. (Though
the indirection is completely transparent to the user)
 
> > > 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.

Its mainly a question of how much it is worth adding code for
quite specialized situations...
 
> > > 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?

I think it was there, and got moved (see the comment above it) when
a special user-signal mechanism was proposed. The user-signal
mechanism was then integrated back into the main signal mechanism, 
but the code didn't get moved back.
 
> IMHO, handlers returning values is just syntactic sugar, though.. not sure if
> it's worth the marshalling overhead..

Never underestimate the power of syntactic sugar. (Why hasn't
Scheme taken over the world?)
 
> 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.

[...]
 
> (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.

Any user who allocates GDK types manually gets what they deserve. In
some cases, there are both public fields and private fields. (See
GdkColormap for an example). (Using automatically allocated GdkEvents 
safe in some restricted circumstances)
 
> 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..
 
I'm not expert enough to say. It could conceivable make a difference
for some compilers and/or some debuggers. I certainly can't read
Peter's mind on the issue.

> 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. 

None of the widgets are going to draw correctly if you set their
bg pixmaps to null. (=> transparent background, for those not
familiar with Xlib details). So I can't really see this as a major
deficiency.
 
> And second, has there been any thought of caching successive expose events?
> This shouldn't been too hard to do..

There has been though given to it. Jay Painter even has a simple
preliminary test patch. Something smarter and more complex is
one of the planned short-term enhancements to GTK. Raph Levien
is the resident expert in this area.

Regards,
                                        Owen