Re: why are signal identifiers strings?

[Owen Taylor <otaylor gtk org>]

Sami Juhani Kallio <samik@eiffel.com> writes:

> Sorry if this is a FAQ, but I didn't find any answer in the
> documentation. I was not able to think of any good reason why signal
> identifiers are strings like "clicked" instead of integer constants
> (CLICKED).

I wouldn't call it a FAQ. But it has been asked before. Here's
how I responded:

From: Owen Taylor <owt1@cornell.edu>
Date: 07 Apr 1998 17:15:51 -0400
Subject: Why strings? (was Re: GTK problem)

Trever Adams <arabian@onramp.net> writes:

> Below is a segment of code that seems like the hard way of doing
> something.  Notice the strings "changed" "clicked" and "value_changed"
> in this code fragment and your own code.  Why do we use strings instead
> of constants/defines?  It takes more to compare strings than constants.
> Is there a good reason to do it this way instead?
> 
>         gtk_signal_connect(GTK_OBJECT(sdata[i]), "value_changed",
>                            GTK_SIGNAL_FUNC(update_sliders), NULL);
>         gtk_signal_connect(GTK_OBJECT(entry[i]), "changed",
>                            GTK_SIGNAL_FUNC(update_labels), NULL);

I really can't see why changing "clicked" => GTK_BUTTON_SIGNAL_CLICKED
would make things easier. (Except for just marginally faster, maybe)

Strings are used largely because of flexibility. If constants were
used, then it would be a big chore to make sure that every signal
in every widget got a unique constant. 

In GTK, the integer ID's that identify signals are allocated at
runtime, which allows new widgets to be added to GTK without any prior
coordination.

By using hash tables, the performance hit from looking things up
by strings is quite small. (And note that the string => id lookup
does not occur every time a signal is called, but usually only
when you _connect() the signal).

Regards,
                                        Owen