Well, guess again. The documentation describes the old event model:

Events are Perl subs that are called in response to an event that occurred in the user interface, usually generated by an action of the user. For example, a button has a Click event that is called when the user pushes it. The naming convention for events follows the Microsoft Visual Basic's one; its form is:

    OBJECTNAME_Eventname
[download]

(note there's an underscore in between), where OBJECTNAME is the value of the -name option used when creating the object, and Eventname is the event name, eg. Click. So if you have a button named Button1, your Click event will be defined as follows:

    sub Button1_Click {
        # ...do something...
    }
[download]

The code inside will be executed when Button1 gets pressed.

So yeah, it does pollute the namespace. That's why I argued that its good to make the pollution "inaccessable". The new event model uses code refs, but it's quite sparsely documented. See also Re: Global vs. local? (Win32::GUI NEM).

<update>
Since this seems a bit unclear maybe I can clarify. The programmer that uses Win32::GUI does not call the event subroutines himself. The only place you'll usually see "Button1_Click" in the code is in the subroutine declaration. If the programmer has done e.g.

sub Button1_Click { ... }

$main->AddButton(
  -name => 'Button1',
  ...,
);
[download]

then it is the Win32::GUI dispatcher that looks in the symbol table for a subroutine named Button1_Click when the button is clicked. Note again that this is in the old event model. In the new event model you would do

$main->AddButton(
  -name => 'Button1',
  -onClick => sub { ... },
  ...,
);
[download]

</update>

lodin