|
NAMEReturn::Value - (deprecated) polymorphic return valuesVERSIONversion 1.666005SYNOPSISUsed with basic function-call interface:use Return::Value; sub send_over_network { my ($net, $send) = @_: if ( $net->transport( $send ) ) { return success; } else { return failure "Was not able to transport info."; } } my $result = $net->send_over_network( "Data" ); # boolean unless ( $result ) { # string print $result; } Or, build your Return::Value as an object: sub build_up_return { my $return = failure; if ( ! foo() ) { $return->string("Can't foo!"); return $return; } if ( ! bar() ) { $return->string("Can't bar"); $return->prop(failures => \@bars); return $return; } # we're okay if we made it this far. $return++; return $return; # success! } DESCRIPTIONPolymorphic return values are a horrible idea, but this library was written based on the notion that they were useful. Often, we just want to know if something worked or not. Other times, we'd like to know what the error text was. Still others, we may want to know what the error code was, and what the error properties were. We don't want to handle objects or data structures for every single return value, but we do want to check error conditions in our code because that's what good programmers do.When functions are successful they may return true, or perhaps some useful data. In the quest to provide consistent return values, this gets confusing between complex, informational errors and successful return values. This module provides these features with a simplistic API that should get you what you're looking for in each context a return value is used in. AttributesAll return values have a set of attributes that package up the information returned. All attributes can be accessed or changed via methods of the same name, unless otherwise noted. Many can also be accessed via overloaded operations on the object, as noted below.
DO NOT USE THIS LIBRARYReturn::Value was a bad idea. I'm sorry that I had it, sorry that I followed through, and sorry that it got used in other useful libraries. Fortunately there are not many things using it. One of those things is Email::Send which is also deprecated in favor of Email::Sender.There's no reason to specify a new module to replace Return::Value. In general, routines should return values of uniform type or throw exceptions. Return::Value tried to be a uniform type for all routines, but has so much weird behavior that it ends up being confusing and not very Perl-like. Objects that are false are just a dreadful idea in almost every circumstance, especially when the object has useful properties. Please do not use this library. You will just regret it later. A release of this library in June 2009 promised that deprecation warnings would start being issued in June 2010. It is now December 2012, and the warnings are now being issued. They can be disabled through means made clear from the source. FUNCTIONSThe functional interface is highly recommended for use within functions that are using "Return::Value" for return values. It's simple and straightforward, and builds the entire return value in one statement.
METHODSThe object API is useful in code that is catching "Return::Value" objects.
OverloadingSeveral operators are overloaded for "Return::Value" objects. They are listed here.
AUTHORS
CONTRIBUTORS
COPYRIGHT AND LICENSEThis software is copyright (c) 2005 by Casey West.This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
Visit the GSP FreeBSD Man Page Interface. |