in reply to Re^2: Missing object reference in sub
in thread Missing object reference in sub

I'm confused. At one point you say the constructor never returns, but the example shows using it in assignment and in code afterward. For my possibly helpful reply, I'm assuming that it does return.

package Frontier::NotReally; sub new { my $class = shift; my %p = @_; return bless \%p, $class; } sub id { my $self = shift; return "$self"; } sub call { my $self = shift; return $self->{sub}->( @_ ); } package main; my $id; $id = Frontier::NotReally->new( sub => sub { print "insub: ", $id->id( +), "\n" } ); print "outsub: ", $id->id(), "\n"; $id->call( 'sub' ); __END__ outsub: Frontier::NotReally=HASH(0x6f1940) insub: Frontier::NotReally=HASH(0x6f1940)

I don't know how much my mockup, Frontier::NotReally, matches the actual Frontier::Daemon you're dealing with, but it's close enough by my understanding. The important part of this example is that my lexical declaration of $id comes before its actual assignment.

my $id; # now $id exists! $id = F::D->new( foo => sub { 'here, $id exists too' } );
What happens is that at the time you call the constructor, $id is undef. Once the constructor finishes, $id has the object's reference in it, and the anonymous sub you passed into the constructor can use it. This won't work if the constructor itself is calling your callback, but any time after that, you'll have the object ready to work with.

Update: I see chromatic has explained faster than I have.

Replies are listed 'Best First'.
Re^4: Missing object reference in sub
by almut (Canon) on Sep 26, 2007 at 22:10 UTC
    ... I'm assuming that it does return.

    I think it doesn't. The source goes something like this:

    sub new { ... while ($conn = $self->accept) { # serve request } }

    i.e., before returning, it enters an accept loop, as typical for daemons listening on a socket.