Re^4: Global vs. local?

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

Comment on Re^4: Global vs. local? Select or Download Code

Replies are listed 'Best First'.
Re^5: Global vs. local? by shmem (Chancellor) on May 29, 2009 at 17:44 UTC
`sub Button1_Click { # ...do something... }` [download] Huh? That's definitely a valid subroutine proper, as opposed to `sub 1Button_Click {}` right? If the old model uses typeglobs but can resolve weird names, then there's messy-symbol-table-lookup and reference-taking-from-typeglobs going on under the hood without need (since sub references could be used as callbacks in the first place.) Not the kind of code I'd consider sane. OTOH, if such weird lookup doesn't tale place, then your of of luck with subs constructed as the OP did, since illegal typeglobs aint for subroutine dispatch, only for internal variables.	[reply] [d/l] [select]
Re^6: Global vs. local? by Corion (Patriarch) on May 29, 2009 at 17:52 UTC
While the name is weird, if you're using a variable to hold it, you can perfectly call the subroutine through that name. And using weird names is good for named subroutines that get autogenerated by code: `my $subname = '1Button_Click'; *{$subname} = sub { print "Hello World\n"; }; no strict 'refs'; $subname->();` [download]	[reply] [d/l]
Re^7: Global vs. local? by shmem (Chancellor) on May 29, 2009 at 18:04 UTC
And using weird names is good for named subroutines that get autogenerated by code The question is wether it is good to name subroutines autogenerated by code in the symbol table. With a dispatch table hash you can name your subroutines by chunks of jpeg files, nice. But symbol tables are namespaces and their entries good for importing/exporting/localizing. I'd rather expect programmers to adhere to perl principles here. Q: Why do you do that? A: Because I can!	[reply]


more useful options
	PerlMonks