in reply to Re: Re: Callback Design
in thread Callback Design

Hmm. Let me see if I understand: you want to be able to do something like grep or map, where your code gets passed a subref which you then call back?

If so, you don't need to worry about changing packages at the time you call it, since it will have already picked up the proper package when it was defined (and compiled) in the caller's code: 

package my;
$global = 'in_my';

sub own_map(&@) {
  my $code = shift;
  my @return = ();
  push @return, $code->() for @_;
  @return;
}

package main;
$global = 'in_main';

print my::own_map { $_, " ", $global, "\n" } (1..20);
  # prints "1 in_main\n", "2 in_main\n" and so on

[download]
In the above code, my::own_map could have molested ${ (caller)[0] . "::global" } to pass a value in to the block. I guess this might be OK (although it's clearly an abuse of caller, which AFAIK was intended for debugging), as long as it's well documented and you are careful to localize everything.

Updated: removed a confusing and unneeded $_ argument on the line that calls the callback. Oops!

Replies are listed 'Best First'.
Re: Re: Re: Re: Callback Design
by MeowChow (Vicar) on Jan 16, 2001 at 05:34 UTC
    Ah, you just showed me something cool, that I can do without the 'sub' declaration if I prototype the callback-setter.

    But I guess I'm not being very clear as to my primary objective. I would like to have something like the following: 

    package MyModule;

my $callback;

sub set_callback {
  $callback = shift;
}

sub exec_callback {
  # the next three lines don't work, but they are indicative of what I
+ would like
  # to see happen... i want $name, $street, $city, $zip to be made ava
+ilable as package
  # globals to the anonymous callback sub... in other words, I don't w
+ant the callback
  # to execute in it's own package, I want it to execute in MyModule::
+ThrowAway
  package MyModule::ThrowAway;
  our ($name, $street, $city, $zip) = @_;
  &$callback();
  package MyModule
}

package main;

# set callback to check that name and zip are both correctly formatted
# notice that callback sub assumes that $name and $zip have been set f
+or it, not
# passed in @_
#
MyModule::set_callback(sub { $name =~ /^[a-zA-Z\s]+$/ and $zip /^\d+$/
+ })

MyModule::exec_callback('Bob', '600 1st St.', 'Beverly Hills', 90210);

    [download]
    Now that I think about it, this could never work under use strict, since $name and $zip are undeclared at the time the callback sub is formed.

    update: cleared up a few confusing things in my code

[reply]
[d/l]
[select]
      Is there some reason why you couldn't just have your module export the variables you'd like to expose to it's users? :)

      package MyModule;
use vars qw(@ISA @EXPORT_OK $name $street $city $zip);
BEGIN {
  @ISA = qw(Exporter);
  @EXPORT_OK = qw($name $street $city $zip);
  require Exporter;
}

my $callback;

sub set_callback(&) { $callback = shift }

sub exec_callback {
  local(($name, $street, $city, $zip) = @_);
  $callback->();
}

package Main;
BEGIN { import MyModule qw($name $street $city $zip) }

MyModule::set_callback { $name =~ /^[a-zA-Z\s]+$/ and $zip =~/^\d+$/ }
+;

MyModule::exec_callback('Bob', '600 1st St.', 'Beverly Hills', '90210'
+)
        and print "Record is valid.\n";

      [download]
      Once MyModule was moved into it's own file, you could replace the ugly BEGIN { import ... } line with just use MyModule qw($name $street $city $zip).

[reply]
[d/l]
[select]
        Good point, but I would ideally like to avoid polluting my module caller's namespace with a bunch of variables. If it came down to choosing between this and $$_{street}, I would probably go with the latter. What do you think?
[reply]

In Section Seekers of Perl Wisdom