Re^3: OO design: returning string and/or special value

OK I think I misread / elided some of your OP where you said that both values were strings. In that case C::R probably isn't what you're wanting, unless you wanted to return a magical hashref that had both values that stringified to the string bit (disclaimer I've never really used C::R in anger, just aware of it's presence).

use Contextual::Return;

sub blahblah {
  ## ...
  return (
    STR { _special_to_string( $retval ); }
    HASHREF { +{ special => $retval, string => _special_to_string( $re
+tval ) }; }
  );
}

my $foo = blahblah( @some_args );
say "Foo: $foo";
say "Special from foo: ", $foo->{special};
[download]

There's also Object::Result which is a variation on the theme which is aimed at making it "easier" to return an instance with arbitrary methods; I believe it's mentioned/recommended in the updated PBP course, for whatever that's worth.

After thinking over it a bit more I think I'd lean towards just a hashref, maybe Object::Result; and eschew overloading or other magic. If you name the slot with the plain string well you probably win in clarity what you lose in extra typing (say $result->{message}).

Then again I drove 900+ miles this weekend so take that with a large grain of salt.</handwaving>

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re^3: OO design: returning string and/or special value Select or Download Code

Replies are listed 'Best First'.
Re^4: OO design: returning string and/or special value by wanna_code_perl (Friar) on Oct 07, 2019 at 22:31 UTC
`$obj->string / $obj->special` was what I originally went with, and I may still do. I came here hoping for some hints on possibly simplifying it, though, as `string` is the 95% case. I rate the odds of the programmer forgetting to write `my $special = $obj->method->special` at least as high as forgetting to write `my (undef, $special) = $obj->method</p>. Since both are strings (and strings are indeed the best option), both would silently use the "wrong" value if forgotten. <c>wantarray` might actually be slightly superior, in that the two calling options look very different and errors would hence be easy to spot: `my $string = $obj->method; # vs. my $string = $obj->meth +od->string; my (undef, $special) = $obj->method; # vs. my $special = $obj->meth +od->special;` [download] I'll give it some more thought though. Thanks for the input.	[reply] [d/l] [select]
Re^5: OO design: returning string and/or special value by AnomalousMonk (Archbishop) on Oct 07, 2019 at 23:52 UTC
... vast majority of the time, the caller is going to want that value in plain old string format.... sometimes they want both string and special formats from the same call ... How about just use good old wantarray to either: `c:\@Work\Perl\monks>perl -wMstrict -MData::Dump -le "sub flexi { my ($str) = @_; ;; my ($string, $special) = map { uc, scalar reverse } $str; ;; return wantarray ? (string => $string, special => $special) : $string ; } ;; my %hash = flexi('foobar'); dd \%hash; ;; my $string = flexi('foobar'); dd $string; " { special => "raboof", string => "FOOBAR" } "FOOBAR"` [download] or: `c:\@Work\Perl\monks>perl -wMstrict -MData::Dump -le "sub flexi { my ($str) = @_; ;; my ($string, $special) = map { uc, scalar reverse } $str; ;; return wantarray ? ($string, $special) : $string ; } ;; my $string1 = flexi('foobar'); dd $string1; ;; my ($string2, $special) = flexi('foobar'); dd $string2, $special; " "FOOBAR" ("FOOBAR", "raboof")` [download] Give a man a fish: `<%-{-{-{-<`	[reply] [d/l] [select]