Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re: Finding the end of a method-chain

by Eily (Deacon)
on Nov 06, 2013 at 13:43 UTC ( #1061430=note: print w/ replies, xml ) Need Help??


in reply to Finding the end of a method-chain

it fails under threads
How so? I didn't see anything about threads in the documentation of Want.

You probably already know that, but just in case I'll say it anyway: in your exemple, there is no object created, since the first parameter passed to funky is actually "FOO" (and so on to every following method). In the end, your autoload sub only returns a new object if you call it in a way that does not look object oriented (without the -> operator).

And last thing, instead of if not you can use unless


Comment on Re: Finding the end of a method-chain
Download Code
Re^2: Finding the end of a method-chain
by std3rr (Novice) on Nov 07, 2013 at 08:02 UTC

    Hello Eily!

    You'll get segmentation fault. Just try:
    perl -Mthreads -MWant -e 'threads->create(sub{want("OBJECT")})->join'

    ... you know what? ..You're right! I did'nt realize that I just passed "FOO". :)
    It was a bad example.
    You could actually remove the bless totaly and It will still work. Anyway, the output is still as expected. The example and the want condition, works. I guess its because Want recognize it as wanting a "OBJECT" as we refer to the methods with '->'.

    The Want module is wonderfull and does what I want, but I could'nt get around the segfault under threads.

    So I still wonder if this particular finding-the-chain-tail can be done threadsafe or maybe in any other fashion? :)

      Alright, I should have seen that, or at least tried it. The problem is that create is called before join (obviously) so the way the return of join will be used is unknown at that time. threads allows you to indicate in which context you want your sub to be called (void, scalar or list) (and if you didn't know that, you probably always called your sub in a scalar context), but not to indicate what will be done of the returned value(s).

      Unless the sub passed as a parameter to threads->create can be your tail method, you could just check (caller 1)[3] eq '(eval)' before trying to use want.

      If this sub can be your tail method, be sure to add {'void' => 1} as the first parameter to threads->create when you're not going to use the return of join(). Then you could have: print " ..and Im a tail!\n" unless defined wantarray and want "OBJECT"

      This is probably a bad idea if you want to be able to use the return value of your method, which can be called by thread->create, and can be the tail method. Why are trying to do that by the way? Maybe you've just set foot on a XY Problem and could avoid using want altogether.

        The oneliner was just a simple reproduction of the segfault, not that I wanted to get anything else out of it.

        I like the abillity to decide what to return depending on where Im at in the chain. You can have polyfunctional methods with same name returning diffrent depending on this.
        Not that I 'must' do this or cant solve this programming structure/functionality in any other way(hey, this is perl ;), but I liked the ability.

        It would be cool to have a "caller"-function for these chains, but as I guess the stack doesnt gets pushed an popped in the same manner, so its trickier.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1061430]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (13)
As of 2014-12-18 22:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (66 votes), past polls