in reply to Re^5: Doing two things at once, fork question. (thread + method)
in thread Doing two things at once, fork question.

The ->can case is just Perl's broken (or at least picky and somewhat perverse) prototypes so you can work around it easily enough with: 

&async( $o->can("method"), $o, ... );

[download]

Note the leading ampersand. Though I wouldn't recommend this hack even if the ambersand wasn't required.

The other problem was error(s) on your part. 

async{ sub{ $o->method­( qw[ the quick brown fox ] ) } };;

[download]

Note that you used a curly brace not a paren. After fixing that I still occasionally didn't get output so I added a sleep in the main thread.

I certainly wasn't trying to make the case that using objects in Perl threads were worthwhile, obviously.

But I'm not sure that there is any benefit to the extra level of indirection.

I consider "not hard-coding method selection" a fine benefit, especially since what class a method actually comes from is an implementation detail that the user of the object shouldn't be bothered with much less be relying upon. Then there is the possiblity of an object that is aware of "method" context and so breaks with your hack.

Adding a simple pair of braces (with or without "sub", depending on your paren choices and the vagaries of Perl prototypes) to a normal method invocation seems a much better idea than hard-coding a method selection and then listing the object after that. The benefit on clarity of code (even if the code mostly doesn't work because Perl threads still rather suck) is quite significant.

- tye        

Replies are listed 'Best First'.
Re^7: Doing two things at once, fork question. (thread + method)
by BrowserUk (Patriarch) on Mar 08, 2008 at 10:08 UTC
    I consider "not hard-coding method selection" a fine benefit, especially since what class a method actually comes from is an implementation detail that the user of the object shouldn't be bothered with much less be relying upon.

    Okay, I see where you are coming from. I guess that reflects how little use I make of Perl's OO. It was my expectation that taking a reference to a method would do whatever method resolution was required. I even tried it out: 

    C:\test>p1
use threads;;
{ 
    package t1; 
    sub new{ bless [], $_[ 0 ] }; 
    sub method{ print __PACKAGE__ . ": @_" } 
};;
{ 
    package t2; 
    our @ISA = 't1'; 
    sub method2{ print __PACKAGE__ . ": @_" } 
};;

$o = t2->new;;
print $o;;
t2=ARRAY(0x22b00c)

$o->method2( 1 .. 5 );;
t2: t2=ARRAY(0x22b00c) 1 2 3 4 5

$o->method( 1 .. 5 );;
t1: t2=ARRAY(0x22b00c) 1 2 3 4 5

print \&t2::method;;
CODE(0x22afac)

    [download]

    Of course the problem was I didn't look closely enough at that coderef to realise that it had a autovivfied a coderef for an inherited method. If I had tried invoking it: 

    \&t2::method->( 1 .. 5 );;
[Undefined subroutine &t2::method called at (eval 13) line 1

    [download]

    but what is worse, having taken that reference to the inherited method, it permentantly screws up the method resolution: 

    $o->method( 1 .. 5 );;
[Undefined subroutine &t2::method called at (eval 14) line 1

    [download]

    Nasty!

    This is certainly the case in other OO languages I used that support first class functions and OO. I don't recall ever having a problem passing a method around in Smalltalk, D, Q, Clean, Mozart, Ocaml, .... Even C++ has delegates these days.

    Is it surprising that Perl OO and threads don't mix well, when Perl OO is so fragile?

    /me will wait patiently for Perl6 before I get heavily into writing OO Perl methinks.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom