Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: chaining method calls

by samtregar (Abbot)
on Jun 12, 2003 at 06:15 UTC ( #265284=note: print w/ replies, xml ) Need Help??


in reply to chaining method calls

I'm definitely not a fan of this call-style. My prefered syntax for accessor/mutators is to have a single method which sets the value if passed a parameter and always returns the current value. This yields calls that read easily and behave in a consistent manner. If $train->speed returns the speed of the train why would $train->speed(10) return the train? It only makes sense if you're already familar with the syntax hack it supports, which isn't even in common usage! Hello maintainance nightmare.

I find the argument (put forth by others) that returning an object on success or undef on failure aids debugging to be totally bogus. Let's take your example:

print SOAP::Lite -> uri('http://www.soaplite.com/Temperatures') -> proxy('http://services.soaplite.com/temper.cgi') -> f2c(32) -> result;

What happens if f2c() fails? Fatal error with a strange error message. What happens if result() fails? Nothing! Maybe you get a warning, but you certainly don't get an error. It's much, much better if mutators croak() if they can't perform their duty. Then error checking is entirely optional, yet still available via eval{}.

-sam

PS: All that said, I'm still a big fan of SOAP::Lite. It's got its quirks, but it gets the job done. To all the SOAP::Lite haters in the audience (and I know you're out there) I'm eagerly awaiting your complete SOAP implementations!


Comment on Re: chaining method calls
Select or Download Code
Re^2: chaining method calls
by adrianh (Chancellor) on Jun 12, 2003 at 10:08 UTC
    It only makes sense if you're already familar with the syntax hack it supports, which isn't even in common usage! Hello maintainance nightmare.

    In the code I've been dealing with it seems to be about a 50/50 split between those who do or don't use the idiom. Possibly the codebases I've been dealing with are biased but in my experience the idiom is in fairly common usage.

    What happens if result() fails? Nothing! Maybe you get a warning, but you certainly don't get an error. It's much, much better if mutators croak() if they can't perform their duty. Then error checking is entirely optional, yet still available via eval{}.

    While I feel that tye's proposal is a little too clever for it's own good - you would get an error if the method failed.

    The method would return an error object on failure. This error object would not get evaluted in a boolean context. On GC the DESTROY method would then croak.

    While it's not a strategy I'd use (sorry tye - not convinced ;-) you would get an error.

    If you use an exception throwing style of error handling then it's not a problem at all.

      You don't even think timely, well-ordered destructors are important. So what do you know? ;)

      The idea is very DWIM and so I think it fits well with Perl. If Perl had better standardization/tools for exception handling, then I'd likely use that much more instead. As is, exception handling in Perl is what I consider to be an "uncommon practice" and likely to surprise people so I usually avoid it (and I regretted one case I can think of where I didn't and in the next release of the module I removed exception throwing).

      Because Perl has timely destructors, I don't mind using them. I find them very powerful. There are things that can be done very cleanly in timely destructors that are just plain hard to do without (lock this and without having to remember to put in any code elsewhere, I know the lock will be released when I leave this block; allocate this exclusively and free when we are done with it).

      The idea of not having well-ordered destructors just boggles my mind. But that is for another thread.

      I also find the distinction between exception and failure (so return a false value) to be a pretty slippery one. One of my favorite things about this idea is that I don't have to decide. I enable you, the module user, to decide which one you want to use and to change your mind depending on the situation.

      I also like that it detects coding mistakes where you forget to check whether something failed or not. I really think all Perl's built-in functions should be capable of behaving this way (like use Fatal qw( :void ... ) almost does) at least optionally.

                      - tye
        "The idea of not having well-ordered destructors just boggles my mind. But that is for another thread."

        Mine too. Back to the issue at hand, I don't normally use the FOO->bar->base syntax. I think it would be best in well defined interfaces though with objects/methods that have a psuedo random relationship, it seems like it would be an ugly scene.

        -Lee

        "To be civilized is to deny one's nature."
        You don't even think timely, well-ordered destructors are important. So what do you know? ;)

        Meow :-)

        The idea is very DWIM and so I think it fits well with Perl.

        It is an cute hack and I like the concept. However, unless I am misunderstanding your proposal there are areas where it can cause non-obvious behaviour - unless you're careful.

        For example, assuming method_that_fails returns an error object like the one you outlined:

        { # Would I expect a scope change to radically alter the time an # error is reported? # $x dies at the end of the block # $y dies at some indeterminate time in the future. my $x = Foo->new->method_that_fails->foo; our $y = Foo->new->method_that_fails->foo; }; # This will fail silently because $bar is an error object, $bar->next # will just return $self, which is then evaluated in a boolean context # so the DESTROY won't give an error. Would I remember to catch the # error explicitly in situations like this? What if that while loop # was off in another module? my $bar = $foo->method_that_fails while ($bar->next) { print $bar->current, "\n" }; # Would I expect an error about Foo creation when Bar objects # are destroyed? sub Bar::new { bless { foo => Foo->new->method_that_fails }, shift };

        I know that we had this conversation before but the scoping issue didn't occur to me then. It seems fairly easy to come up with scenarios where the error object doesn't get DESTROYed for quite some time.

        I can see this, in combination with AUTOLOADed methods returning the error object, resulting in errors being ignored or reported a long way from where they occurred.

        As is, exception handling in Perl is what I consider to be an "uncommon practice" and likely to surprise people so I usually avoid it

        Personally I find that exceptions help more than they hinder. I like keeping the error handling from obscuring the mainline. I've made my arguments for exceptions elsewhere so I won't repeat myself here ;-) YMMV.

        Because Perl has timely destructors, I don't mind using them. I find them very powerful. There are things that can be done very cleanly in timely destructors that are just plain hard to do without

        Agree completely. I use them myself on occasion.

        The idea of not having well-ordered destructors just boggles my mind. But that is for another thread.

        The idea of not having some sort of scoped action/finalization mechanism in a language boggles my mind. I just don't think it needs to be duct taped to an otherwise, for me, bleeding annoying memory management system :-)

        I also find the distinction between exception and failure (so return a false value) to be a pretty slippery one.

        It is an interesting distinction. It's not so much between exception and failure as between expected and erroneous behaviour. Is the fact that open returns false an error ("You asked me to open this and I can't. Ack!") or an informative return value ("You asked me to open this if I could and I couldn't. Just thought I'd let you know."). As you correctly point out it's context dependent.

        One of my favorite things about this idea is that I don't have to decide. I enable you, the module user, to decide which one you want to use and to change your mind depending on the situation.

        It is a nice idea but I think there are enough (pardon the pun) exceptions to the DWIMish behaviour to make the error object you suggested more trouble than it's worth.

        I really think all Perl's built-in functions should be capable of behaving this way (like use Fatal qw( :void ... ) almost does) at least optionally.

        Amen. I was so happy when I first discovered Fatal. Then sad to find all the cases where it doesn't work. Hey ho.

Re^2: chaining method calls (same difference)
by Aristotle (Chancellor) on Jun 13, 2003 at 01:43 UTC
    What happens if result() fails? Nothing!
    Which is no less than what happens if it failed in traditional
    print $soap->result;
    style.

    Makeshifts last the longest.

      So, uh, we agree then. The argument that chaining helped debugging is false. Both styles have the same problems. Good!

      -sam

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2014-08-20 05:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (105 votes), past polls