in reply to Global vs. local?

foreach my $j (0..$i-1) {
    $SUB = $j."Textfield_MaxText";
    ...
        *$SUB = sub { variableMaxText(0); };

[download]

This will create a typeglob with an illegal subroutine name - sub names may not start with a digit. You can do that, but the sub can not be called directly by name: 

$SUB = "1Foo";
*$SUB = sub {print "$SUB!\n"};
1Foo();
Bareword found where operator expected at -e line 3, near "1Foo"
        (Missing operator before Foo?)

[download]

To call that weird sub, you'd have to do 

$SUB = "1Foo";
*$SUB = sub {print "$SUB!\n"};
&{"1Foo"};
__END__
1Foo!

[download]

Replies are listed 'Best First'.
Re^2: Global vs. local?
by lodin (Hermit) on May 28, 2009 at 13:53 UTC

    the sub can not be called directly by name

    The subroutine is not called directly, but rather dispatched by the Win32::GUI event model. Ignoring that there are better ways to handle event definitions altogether, that's an argument for doing precisely what jpavel does. That way the Win32::GUI event handlers won't accidentally collide with any "regular" subroutines in the program.

    lodin

[reply]
      The subroutine is not called directly, but rather dispatched by the Win32::GUI event model.

      How is the sub accessed by the event handler?

      Ignoring that there are better ways to handle event definitions altogether, that's an argument for doing precisely what jpavel does.

      No, it's not. Polluting the name space with funny things is not a good idea. I don't know about Win32::GUI, but I guess it uses coderefs rather than typeglobs. If it doesn't, then I hope for never needing to look at that module.

[reply]

        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

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom