Re: [java-gnome-hackers] Methods that emit signals

[Andrew C. <an...@op...>]

On Wed, 2007-11-28 at 08:14 +0000, Nat Pryce wrote:
> On 27/11/2007, Andrew Cowie <an...@op...> wrote:
> > ... I am tempted to present all such methods with their own prefix to
> > make their relationship to the signal clear.
> >
> > Inspired by the "on" Owen Taylor suggested that led to the onClicked()
> > in design of the Button.CLICKED interface for 'clicked' signals, I'm
> > thinking:
> >
> >         doClicked()
> >         doRowActivated()
> >
> > etc


> If you're going to change the names away from the Gtk conventions I
> personally would like to see the new names follow Java norms.  In Java
> libraries, the "fire" prefix is usually used to send event callbacks
> to listeners.  E.g. "fireClicked()" and "fireRowActivated()" would
> send "clicked()" and "rowActivated()" callbacks respectively.

That's a nice suggestion.

> However, "fire" methods are usually protected,=20

Ok, so much for that.

> to ensure that events
> are not announced except when the object actually makes the state
> change that is being announced.  Public methods that result in events
> being fired are conventionally in the imperative mood but relate to
> the object's responsibilities, not to its event-firing mechanism.

Yeah, that bothered me a bit too, but given that some signals are named
with a word that can be taken as being in the imperative tense, and some
are in other tenses, it's kinda hard to normalize.

Having been grubbing around down in the C side guts a bit lately, the
"faithful to GTK" aspect is actually that methods like
gtk_button_clicked() are actually convenience wrappers around what is
effectively g_signal_emit('clicked').

So we'll stick with mapping the signal name as is (without attempting to
normalize the tense or tone or mood of the name), but use the word
"emit" as a prefix. I've just committed emitClicked() to Button.

Thanks to everyone for your input.

AfC
Melbourne